From owner-atom-syntax@mail.imc.org Fri Sep 01 00:41:54 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GJ0qo-0007io-KJ
	for atompub-archive@lists.ietf.org; Fri, 01 Sep 2006 00:41:54 -0400
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1GJ0qk-00071T-6i
	for atompub-archive@lists.ietf.org; Fri, 01 Sep 2006 00:41:54 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k810wldd005981;
	Thu, 31 Aug 2006 17:58:47 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id k810wl9f005980;
	Thu, 31 Aug 2006 17:58:47 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.168])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k810wkJR005966
	for <atom-syntax@imc.org>; Thu, 31 Aug 2006 17:58:46 -0700 (MST)
	(envelope-from xmlhacker@gmail.com)
Received: by ug-out-1314.google.com with SMTP id m3so773055uge
        for <atom-syntax@imc.org>; Thu, 31 Aug 2006 17:58:45 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references;
        b=Ig+7eqC8mxI+3rFbWkQRPVLFTPLSKiJ1MQN8I4gKfGBipNiRRxwckzmGZ4acTSmqR6F5u7fa4F/E0V+pROdbyH7Mw0k+DRS34LCjeC7aeDv46JEd4RU3VZs3yZeC70TsrCetYnpbWBJU0JARce5VdL9dWluMMfzC7D11LV/40ek=
Received: by 10.67.101.10 with SMTP id d10mr868542ugm;
        Thu, 31 Aug 2006 17:58:45 -0700 (PDT)
Received: by 10.66.217.10 with HTTP; Thu, 31 Aug 2006 17:58:44 -0700 (PDT)
Message-ID: <eab75e160608311758m1baec868w90d8ce6bb4cb4cbb@mail.gmail.com>
Date: Thu, 31 Aug 2006 18:58:44 -0600
From: "M. David Peterson" <xmlhacker@gmail.com>
To: "atom-syntax Syntax" <atom-syntax@imc.org>
Subject: Re: Can/Does/Should the FeedValidator catch improperly escaped XHTML?
In-Reply-To: <20060901000154.GA19253@klangraum>
MIME-Version: 1.0
Content-Type: multipart/alternative; 
	boundary="----=_Part_71502_25481682.1157072324974"
References: <eab75e160608301730x2aabede1kd4bff14b34fd7ed5@mail.gmail.com>
	 <44F6CD20.803@intertwingly.net> <op.te51uxnq16f2qb@quark>
	 <BAY120-DAV5E440BA44B1B721B308D5BE3F0@phx.gbl>
	 <20060901000154.GA19253@klangraum>
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa


------=_Part_71502_25481682.1157072324974
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Both points well taken.

I would like to change my initial vote to -1, though +1 for both James and
Aristotle's follow-up.

On 8/31/06, A. Pagaltzis <pagaltzis@gmx.de> wrote:
>
>
> * James Holderness <j4_james@hotmail.com> [2006-09-01 01:30]:
> > Encouraging people to use xhtml when they don't know enough to
> > have made that decision themselves is just asking for trouble.
>
> +1
>
> Regards,
> --
> Aristotle Pagaltzis // <http://plasmasturm.org/>
>
>


-- 
/M:D

M. David Peterson
http://mdavid.name | http://www.oreillynet.com/pub/au/2354

------=_Part_71502_25481682.1157072324974
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Both points well taken.<br><br>I would like to change my initial vote to -1, though +1 for both James and Aristotle's follow-up.<br><br><div><span class="gmail_quote">On 8/31/06, <b class="gmail_sendername">A. Pagaltzis</b>
 &lt;<a href="mailto:pagaltzis@gmx.de">pagaltzis@gmx.de</a>&gt; wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>* James Holderness &lt;
<a href="mailto:j4_james@hotmail.com">j4_james@hotmail.com</a>&gt; [2006-09-01 01:30]:<br>&gt; Encouraging people to use xhtml when they don't know enough to<br>&gt; have made that decision themselves is just asking for trouble.
<br><br>+1<br><br>Regards,<br>--<br>Aristotle Pagaltzis // &lt;<a href="http://plasmasturm.org/">http://plasmasturm.org/</a>&gt;<br><br></blockquote></div><br><br clear="all"><br>-- <br>/M:D<br><br>M. David Peterson<br><a href="http://mdavid.name">
http://mdavid.name</a> | <a href="http://www.oreillynet.com/pub/au/2354">http://www.oreillynet.com/pub/au/2354</a>

------=_Part_71502_25481682.1157072324974--




From owner-atom-syntax@mail.imc.org Sat Sep 02 06:46:53 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GJT1Z-0002uk-Ee
	for atompub-archive@lists.ietf.org; Sat, 02 Sep 2006 06:46:53 -0400
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1GJT1X-0005FS-2Y
	for atompub-archive@lists.ietf.org; Sat, 02 Sep 2006 06:46:53 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k82ANsLS039755;
	Sat, 2 Sep 2006 03:23:54 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id k82ANsUl039754;
	Sat, 2 Sep 2006 03:23:54 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from spunkymail-a11.dreamhost.com (sd-green-bigip-118.dreamhost.com [208.97.132.118])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k82ANkDe039739
	for <atom-syntax@imc.org>; Sat, 2 Sep 2006 03:23:54 -0700 (MST)
	(envelope-from asbjorn@tigerstaden.no)
Received: from quark (202.84-48-117.nextgentel.com [84.48.117.202])
	by spunkymail-a11.dreamhost.com (Postfix) with ESMTP id 239F0B6C05;
	Sat,  2 Sep 2006 03:23:42 -0700 (PDT)
Date: Sat, 02 Sep 2006 12:23:51 +0200
To: "James Holderness" <j4_james@hotmail.com>,
        "atom-syntax Syntax" <atom-syntax@imc.org>
Subject: Re: Can/Does/Should the FeedValidator catch improperly escaped XHTML?
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
References: <eab75e160608301730x2aabede1kd4bff14b34fd7ed5@mail.gmail.com> <44F6CD20.803@intertwingly.net> <op.te51uxnq16f2qb@quark> <BAY120-DAV5E440BA44B1B721B308D5BE3F0@phx.gbl>
Message-ID: <op.te8xt1si16f2qb@quark>
In-Reply-To: <BAY120-DAV5E440BA44B1B721B308D5BE3F0@phx.gbl>
User-Agent: Opera Mail/9.01 (Win32)
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id k82ANsLS039755
X-Spam-Score: 1.8 (+)
X-Scan-Signature: 97adf591118a232206bdb5a27b217034


On Fri, 01 Sep 2006 01:19:35 +0200, James Holderness =20
<j4_james@hotmail.com> wrote:

> Just because a feed appears to contain well-formed xhtml content today,=
 =20
> that doesn't mean it's going to be well-formed tomorrow. Encouraging =20
> people to use xhtml when they don't know enough to have made that =20
> decision themselves is just asking for trouble. Sooner or later they're=
 =20
> going to end up with broken xml which will be completely unreadable in =
=20
> many aggregators.

Well, that completely depends on how we present this information to the =20
user. I was not thinking of a simple message saying "This is valid XHTML,=
 =20
change @type to 'xhtml' ASAP, you newb!", but more along the lines of =20
informing the user that the content looks like wellformed XHTML, that he =
=20
can read more about it here and there, why he should try to keep it =20
wellformed and why he should not change it if he's not sure of its =20
welformedness.

Something like that.

> Also, escaped html tends to be better supported by aggregators anyway.

That's today. I would hope and assume that this changes in the future.

--=20
Asbj=F8rn Ulsberg     -=3D|=3D-    http://virtuelvis.com/quark/
=ABHe's a loathsome offensive brute, yet I can't look away=BB




From owner-atom-syntax@mail.imc.org Sat Sep 02 07:46:08 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GJTwu-0006F3-Kt
	for atompub-archive@lists.ietf.org; Sat, 02 Sep 2006 07:46:08 -0400
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1GJTwq-0001z7-3i
	for atompub-archive@lists.ietf.org; Sat, 02 Sep 2006 07:46:08 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k82BWkR3044163;
	Sat, 2 Sep 2006 04:32:46 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id k82BWkRq044162;
	Sat, 2 Sep 2006 04:32:46 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.172])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k82BWgbf044154
	for <atom-syntax@imc.org>; Sat, 2 Sep 2006 04:32:45 -0700 (MST)
	(envelope-from xmlhacker@gmail.com)
Received: by ug-out-1314.google.com with SMTP id m3so1207412uge
        for <atom-syntax@imc.org>; Sat, 02 Sep 2006 04:32:41 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references;
        b=aqLQy6b49DqFE49CLAADD4HVuwDrhxjNbZYVXF7eANxeJp8VWDjpy0+5RWW+q+f4PNUZKpeQDdMbgng/wUSev8TSE5YbJCDJl2BGzCl7UJOB1ilu3iJR0K3h2JkzEEpACFBZbFqCytjVRqr0rYYLYsJL5HRbkDpWv3nPLgTVA2Q=
Received: by 10.66.244.10 with SMTP id r10mr1695950ugh;
        Sat, 02 Sep 2006 04:32:41 -0700 (PDT)
Received: by 10.66.217.10 with HTTP; Sat, 2 Sep 2006 04:32:39 -0700 (PDT)
Message-ID: <eab75e160609020432l73d357echbcc909f4189cc52c@mail.gmail.com>
Date: Sat, 2 Sep 2006 05:32:39 -0600
From: "M. David Peterson" <xmlhacker@gmail.com>
To: "=?UTF-8?Q?Asbj=C3=B8rn_Ulsberg?=" <asbjorn@tigerstaden.no>
Subject: Re: Can/Does/Should the FeedValidator catch improperly escaped XHTML?
Cc: "James Holderness" <j4_james@hotmail.com>,
        "atom-syntax Syntax" <atom-syntax@imc.org>
In-Reply-To: <op.te8xt1si16f2qb@quark>
MIME-Version: 1.0
Content-Type: multipart/alternative; 
	boundary="----=_Part_95616_10849110.1157196759775"
References: <eab75e160608301730x2aabede1kd4bff14b34fd7ed5@mail.gmail.com>
	 <44F6CD20.803@intertwingly.net> <op.te51uxnq16f2qb@quark>
	 <BAY120-DAV5E440BA44B1B721B308D5BE3F0@phx.gbl>
	 <op.te8xt1si16f2qb@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>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 00e94c813bef7832af255170dca19e36


------=_Part_95616_10849110.1157196759775
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: base64
Content-Disposition: inline

Pj4gVGhhdCdzIHRvZGF5LiBJIHdvdWxkIGhvcGUgYW5kIGFzc3VtZSB0aGF0IHRoaXMgY2hhbmdl
cyBpbiB0aGUgZnV0dXJlLgoKKzEKCk9uIDkvMi8wNiwgQXNiasO4cm4gVWxzYmVyZyA8YXNiam9y
bkB0aWdlcnN0YWRlbi5ubz4gd3JvdGU6Cj4KPgo+IE9uIEZyaSwgMDEgU2VwIDIwMDYgMDE6MTk6
MzUgKzAyMDAsIEphbWVzIEhvbGRlcm5lc3MKPiA8ajRfamFtZXNAaG90bWFpbC5jb20+IHdyb3Rl
Ogo+Cj4gPiBKdXN0IGJlY2F1c2UgYSBmZWVkIGFwcGVhcnMgdG8gY29udGFpbiB3ZWxsLWZvcm1l
ZCB4aHRtbCBjb250ZW50IHRvZGF5LAo+ID4gdGhhdCBkb2Vzbid0IG1lYW4gaXQncyBnb2luZyB0
byBiZSB3ZWxsLWZvcm1lZCB0b21vcnJvdy4gRW5jb3VyYWdpbmcKPiA+IHBlb3BsZSB0byB1c2Ug
eGh0bWwgd2hlbiB0aGV5IGRvbid0IGtub3cgZW5vdWdoIHRvIGhhdmUgbWFkZSB0aGF0Cj4gPiBk
ZWNpc2lvbiB0aGVtc2VsdmVzIGlzIGp1c3QgYXNraW5nIGZvciB0cm91YmxlLiBTb29uZXIgb3Ig
bGF0ZXIgdGhleSdyZQo+ID4gZ29pbmcgdG8gZW5kIHVwIHdpdGggYnJva2VuIHhtbCB3aGljaCB3
aWxsIGJlIGNvbXBsZXRlbHkgdW5yZWFkYWJsZSBpbgo+ID4gbWFueSBhZ2dyZWdhdG9ycy4KPgo+
IFdlbGwsIHRoYXQgY29tcGxldGVseSBkZXBlbmRzIG9uIGhvdyB3ZSBwcmVzZW50IHRoaXMgaW5m
b3JtYXRpb24gdG8gdGhlCj4gdXNlci4gSSB3YXMgbm90IHRoaW5raW5nIG9mIGEgc2ltcGxlIG1l
c3NhZ2Ugc2F5aW5nICJUaGlzIGlzIHZhbGlkIFhIVE1MLAo+IGNoYW5nZSBAdHlwZSB0byAneGh0
bWwnIEFTQVAsIHlvdSBuZXdiISIsIGJ1dCBtb3JlIGFsb25nIHRoZSBsaW5lcyBvZgo+IGluZm9y
bWluZyB0aGUgdXNlciB0aGF0IHRoZSBjb250ZW50IGxvb2tzIGxpa2Ugd2VsbGZvcm1lZCBYSFRN
TCwgdGhhdCBoZQo+IGNhbiByZWFkIG1vcmUgYWJvdXQgaXQgaGVyZSBhbmQgdGhlcmUsIHdoeSBo
ZSBzaG91bGQgdHJ5IHRvIGtlZXAgaXQKPiB3ZWxsZm9ybWVkIGFuZCB3aHkgaGUgc2hvdWxkIG5v
dCBjaGFuZ2UgaXQgaWYgaGUncyBub3Qgc3VyZSBvZiBpdHMKPiB3ZWxmb3JtZWRuZXNzLgo+Cj4g
U29tZXRoaW5nIGxpa2UgdGhhdC4KPgo+ID4gQWxzbywgZXNjYXBlZCBodG1sIHRlbmRzIHRvIGJl
IGJldHRlciBzdXBwb3J0ZWQgYnkgYWdncmVnYXRvcnMgYW55d2F5Lgo+Cj4gVGhhdCdzIHRvZGF5
LiBJIHdvdWxkIGhvcGUgYW5kIGFzc3VtZSB0aGF0IHRoaXMgY2hhbmdlcyBpbiB0aGUgZnV0dXJl
Lgo+Cj4gLS0KPiBBc2Jqw7hybiBVbHNiZXJnICAgICAtPXw9LSAgICBodHRwOi8vdmlydHVlbHZp
cy5jb20vcXVhcmsvCj4gwqtIZSdzIGEgbG9hdGhzb21lIG9mZmVuc2l2ZSBicnV0ZSwgeWV0IEkg
Y2FuJ3QgbG9vayBhd2F5wrsKPgo+CgoKLS0gCi9NOkQKCk0uIERhdmlkIFBldGVyc29uCmh0dHA6
Ly9tZGF2aWQubmFtZSB8IGh0dHA6Ly93d3cub3JlaWxseW5ldC5jb20vcHViL2F1LzIzNTQK
------=_Part_95616_10849110.1157196759775
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: base64
Content-Disposition: inline

Jmd0OyZndDsgVGhhdCdzIHRvZGF5LiBJIHdvdWxkIGhvcGUgYW5kIGFzc3VtZSB0aGF0IHRoaXMg
Y2hhbmdlcyBpbiB0aGUgZnV0dXJlLjxicj48YnI+KzE8YnI+PGJyPjxkaXY+PHNwYW4gY2xhc3M9
ImdtYWlsX3F1b3RlIj5PbiA5LzIvMDYsIDxiIGNsYXNzPSJnbWFpbF9zZW5kZXJuYW1lIj5Bc2Jq
w7hybiBVbHNiZXJnPC9iPiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFzYmpvcm5AdGlnZXJzdGFkZW4u
bm8iPgphc2Jqb3JuQHRpZ2Vyc3RhZGVuLm5vPC9hPiZndDsgd3JvdGU6PC9zcGFuPjxibG9ja3F1
b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9ImJvcmRlci1sZWZ0OiAxcHggc29saWQgcmdi
KDIwNCwgMjA0LCAyMDQpOyBtYXJnaW46IDBwdCAwcHQgMHB0IDAuOGV4OyBwYWRkaW5nLWxlZnQ6
IDFleDsiPjxicj5PbiBGcmksIDAxIFNlcCAyMDA2IDAxOjE5OjM1ICswMjAwLCBKYW1lcyBIb2xk
ZXJuZXNzCjxicj4mbHQ7PGEgaHJlZj0ibWFpbHRvOmo0X2phbWVzQGhvdG1haWwuY29tIj5qNF9q
YW1lc0Bob3RtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj48YnI+Jmd0OyBKdXN0IGJlY2F1c2Ug
YSBmZWVkIGFwcGVhcnMgdG8gY29udGFpbiB3ZWxsLWZvcm1lZCB4aHRtbCBjb250ZW50IHRvZGF5
LDxicj4mZ3Q7IHRoYXQgZG9lc24ndCBtZWFuIGl0J3MgZ29pbmcgdG8gYmUgd2VsbC1mb3JtZWQg
dG9tb3Jyb3cuIEVuY291cmFnaW5nCjxicj4mZ3Q7IHBlb3BsZSB0byB1c2UgeGh0bWwgd2hlbiB0
aGV5IGRvbid0IGtub3cgZW5vdWdoIHRvIGhhdmUgbWFkZSB0aGF0PGJyPiZndDsgZGVjaXNpb24g
dGhlbXNlbHZlcyBpcyBqdXN0IGFza2luZyBmb3IgdHJvdWJsZS4gU29vbmVyIG9yIGxhdGVyIHRo
ZXkncmU8YnI+Jmd0OyBnb2luZyB0byBlbmQgdXAgd2l0aCBicm9rZW4geG1sIHdoaWNoIHdpbGwg
YmUgY29tcGxldGVseSB1bnJlYWRhYmxlIGluCjxicj4mZ3Q7IG1hbnkgYWdncmVnYXRvcnMuPGJy
Pjxicj5XZWxsLCB0aGF0IGNvbXBsZXRlbHkgZGVwZW5kcyBvbiBob3cgd2UgcHJlc2VudCB0aGlz
IGluZm9ybWF0aW9uIHRvIHRoZTxicj51c2VyLiBJIHdhcyBub3QgdGhpbmtpbmcgb2YgYSBzaW1w
bGUgbWVzc2FnZSBzYXlpbmcgJnF1b3Q7VGhpcyBpcyB2YWxpZCBYSFRNTCw8YnI+Y2hhbmdlIEB0
eXBlIHRvICd4aHRtbCcgQVNBUCwgeW91IG5ld2IhJnF1b3Q7LCBidXQgbW9yZSBhbG9uZyB0aGUg
bGluZXMgb2YKPGJyPmluZm9ybWluZyB0aGUgdXNlciB0aGF0IHRoZSBjb250ZW50IGxvb2tzIGxp
a2Ugd2VsbGZvcm1lZCBYSFRNTCwgdGhhdCBoZTxicj5jYW4gcmVhZCBtb3JlIGFib3V0IGl0IGhl
cmUgYW5kIHRoZXJlLCB3aHkgaGUgc2hvdWxkIHRyeSB0byBrZWVwIGl0PGJyPndlbGxmb3JtZWQg
YW5kIHdoeSBoZSBzaG91bGQgbm90IGNoYW5nZSBpdCBpZiBoZSdzIG5vdCBzdXJlIG9mIGl0czxi
cj4Kd2VsZm9ybWVkbmVzcy48YnI+PGJyPlNvbWV0aGluZyBsaWtlIHRoYXQuPGJyPjxicj4mZ3Q7
IEFsc28sIGVzY2FwZWQgaHRtbCB0ZW5kcyB0byBiZSBiZXR0ZXIgc3VwcG9ydGVkIGJ5IGFnZ3Jl
Z2F0b3JzIGFueXdheS48YnI+PGJyPlRoYXQncyB0b2RheS4gSSB3b3VsZCBob3BlIGFuZCBhc3N1
bWUgdGhhdCB0aGlzIGNoYW5nZXMgaW4gdGhlIGZ1dHVyZS48YnI+PGJyPi0tPGJyPkFzYmrDuHJu
IFVsc2JlcmcmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLT18PS0mbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsKPGEgaHJlZj0iaHR0cDovL3ZpcnR1ZWx2aXMuY29tL3F1YXJrLyI+aHR0cDovL3ZpcnR1
ZWx2aXMuY29tL3F1YXJrLzwvYT48YnI+wqtIZSdzIGEgbG9hdGhzb21lIG9mZmVuc2l2ZSBicnV0
ZSwgeWV0IEkgY2FuJ3QgbG9vayBhd2F5wrs8YnI+PGJyPjwvYmxvY2txdW90ZT48L2Rpdj48YnI+
PGJyIGNsZWFyPSJhbGwiPjxicj4tLSA8YnI+L006RDxicj48YnI+TS4gRGF2aWQgUGV0ZXJzb248
YnI+CjxhIGhyZWY9Imh0dHA6Ly9tZGF2aWQubmFtZSI+aHR0cDovL21kYXZpZC5uYW1lPC9hPiB8
IDxhIGhyZWY9Imh0dHA6Ly93d3cub3JlaWxseW5ldC5jb20vcHViL2F1LzIzNTQiPmh0dHA6Ly93
d3cub3JlaWxseW5ldC5jb20vcHViL2F1LzIzNTQ8L2E+Cg==
------=_Part_95616_10849110.1157196759775--




From owner-atom-syntax@mail.imc.org Mon Sep 04 15:24:56 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GKK40-0003WV-KV
	for atompub-archive@lists.ietf.org; Mon, 04 Sep 2006 15:24:56 -0400
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1GKK3z-0005ey-9C
	for atompub-archive@lists.ietf.org; Mon, 04 Sep 2006 15:24:56 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k84J2Uqt075815;
	Mon, 4 Sep 2006 12:02:30 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id k84J2UdX075814;
	Mon, 4 Sep 2006 12:02:30 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.182])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k84J2Tiw075806
	for <atom-syntax@imc.org>; Mon, 4 Sep 2006 12:02:29 -0700 (MST)
	(envelope-from jasnell@gmail.com)
Received: by py-out-1112.google.com with SMTP id i75so2329619pye
        for <atom-syntax@imc.org>; Mon, 04 Sep 2006 12:02:26 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:user-agent:mime-version:to:subject:content-type:content-transfer-encoding;
        b=g6GrfqJbflYk9B6p7zxUZYTAxK3fSSxQJ3uyhCnVS/vW0qDrVtRresifpJ1Tci7s6w5jHLzxxQ7sdyfOVmqyjsIko+eZ6+2unrTYPCUnu1rT6EcP2B2usMzM8rSJi8Nmvc4qLyzMpuxEWZO33UdAdgpud/TZoAFFTYMi0MapJ90=
Received: by 10.35.41.12 with SMTP id t12mr10742242pyj;
        Mon, 04 Sep 2006 12:02:26 -0700 (PDT)
Received: from ?192.168.1.104? ( [67.181.218.96])
        by mx.gmail.com with ESMTP id x47sm2258946pyc.2006.09.04.12.02.24;
        Mon, 04 Sep 2006 12:02:26 -0700 (PDT)
Message-ID: <44FC783D.7070101@gmail.com>
Date: Mon, 04 Sep 2006 12:02:21 -0700
From: James M Snell <jasnell@gmail.com>
User-Agent: Thunderbird 1.5.0.5 (X11/20060719)
MIME-Version: 1.0
To: atom-syntax <atom-syntax@imc.org>
Subject: XML Digital Signatures in Atom feeds and entries
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 08e48e05374109708c00c6208b534009


I'm currently looking for other Atom implementations that support the
option to digitally sign feeds and entries.  Apache Abdera supports
digital signatures and encryption and I'd like to do some interop
testing against other impls.

- James




From owner-atom-syntax@mail.imc.org Tue Sep 05 13:04:45 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GKeLt-0007L6-J2
	for atompub-archive@lists.ietf.org; Tue, 05 Sep 2006 13:04:45 -0400
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1GKeLp-0006TB-68
	for atompub-archive@lists.ietf.org; Tue, 05 Sep 2006 13:04:45 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k85Gi1YI080368;
	Tue, 5 Sep 2006 09:44:01 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id k85Gi1Jj080367;
	Tue, 5 Sep 2006 09:44:01 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from robin.verisign.com (robin.verisign.com [65.205.251.75])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k85GhwsK080345
	for <atom-syntax@imc.org>; Tue, 5 Sep 2006 09:44:00 -0700 (MST)
	(envelope-from hgranqvist@verisign.com)
Received: from MOU1WNEXCN03.vcorp.ad.vrsn.com (mailer6.verisign.com [65.205.251.33])
	by robin.verisign.com (8.13.6/8.13.4) with ESMTP id k85Ghqnb007801;
	Tue, 5 Sep 2006 09:43:52 -0700
Received: from MOU1WNEXMB02.vcorp.ad.vrsn.com ([10.25.12.244]) by MOU1WNEXCN03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830);
	 Tue, 5 Sep 2006 09:43:10 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Subject: RE: XML Digital Signatures in Atom feeds and entries
Date: Tue, 5 Sep 2006 09:43:12 -0700
Message-ID: <45D459DDA07DC442A499A4D46F4939BA02107F00@MOU1WNEXMB02.vcorp.ad.vrsn.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: XML Digital Signatures in Atom feeds and entries
Thread-Index: AcbQWcvRNkE063YpQC2/SLVKxzaepQAsE7HA
From: "Granqvist, Hans" <hgranqvist@verisign.com>
To: "James M Snell" <jasnell@gmail.com>, "atom-syntax" <atom-syntax@imc.org>
X-OriginalArrivalTime: 05 Sep 2006 16:43:10.0504 (UTC) FILETIME=[5F478A80:01C6D10A]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k85Gi0sK080362
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d


James,

There is an interop service for Atom 1.0 feed/entry signature 
validation available (with source code for both service and 
Wordpress plugin) as part of the Signed Ping initiative at 
  http://signedping.com

Let me know if you need more info.
-Hans 

> -----Original Message-----
> From: owner-atom-syntax@mail.imc.org 
> [mailto:owner-atom-syntax@mail.imc.org] On Behalf Of James M Snell
> Sent: Monday, September 04, 2006 12:02 PM
> To: atom-syntax
> Subject: XML Digital Signatures in Atom feeds and entries
> 
> 
> I'm currently looking for other Atom implementations that 
> support the option to digitally sign feeds and entries.  
> Apache Abdera supports digital signatures and encryption and 
> I'd like to do some interop testing against other impls.
> 
> - James
> 
> 
> 




From owner-atom-syntax@mail.imc.org Tue Sep 05 18:26:24 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GKjNA-00010e-Pu
	for atompub-archive@lists.ietf.org; Tue, 05 Sep 2006 18:26:24 -0400
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1GKjN5-0006aF-0A
	for atompub-archive@lists.ietf.org; Tue, 05 Sep 2006 18:26:24 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k85MBZMa015900;
	Tue, 5 Sep 2006 15:11:35 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id k85MBZ5t015899;
	Tue, 5 Sep 2006 15:11:35 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.233])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k85MBRfH015882
	for <atom-syntax@imc.org>; Tue, 5 Sep 2006 15:11:34 -0700 (MST)
	(envelope-from jasnell@gmail.com)
Received: by wx-out-0506.google.com with SMTP id t12so2409946wxc
        for <atom-syntax@imc.org>; Tue, 05 Sep 2006 15:11:27 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding;
        b=NDTpFIo5Ug7HkX6hfk+uwZJrKFrDT1mC/MtoEHgITldg7xVxb4CmEuWg1ixMP3xlc43XDeGfWw5enKbQXgSbyojbvpacMvO9c3LJKPfFQfCVf7Ju8QLHmnYQHKnpEoWv+7m9IXOADQJaI6nhmxeVJwo1or9QtbXR+nZApoWT1cA=
Received: by 10.90.100.6 with SMTP id x6mr340112agb;
        Tue, 05 Sep 2006 15:11:27 -0700 (PDT)
Received: from ?192.168.1.104? ( [67.181.218.96])
        by mx.gmail.com with ESMTP id 5sm6774887wrh.2006.09.05.15.11.25;
        Tue, 05 Sep 2006 15:11:27 -0700 (PDT)
Message-ID: <44FDF60A.1010508@gmail.com>
Date: Tue, 05 Sep 2006 15:11:22 -0700
From: James M Snell <jasnell@gmail.com>
User-Agent: Thunderbird 1.5.0.5 (X11/20060719)
MIME-Version: 1.0
To: Thomas Roessler <tlr@w3.org>
CC: Mike Linksvayer <ml@creativecommons.org>, Ben Adida <ben@mit.edu>,
        Lisa Dusseault <lisa@osafoundation.org>, wendy@seltzer.org,
        atom-syntax <atom-syntax@imc.org>
Subject: Re: atom license extension (Re: [cc-tab] *important* heads up)
References: <44FD8F55.2010609@mit.edu> <1157478767.18377.47.camel@localhost.localdomain> <1157482144.18377.75.camel@localhost.localdomain> <20060905193613.GX12632@raktajino.does-not-exist.org>
In-Reply-To: <20060905193613.GX12632@raktajino.does-not-exist.org>
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>
X-Spam-Score: 1.9 (+)
X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172


Hello Thomas,

Thank you for taking the time to review the draft.  I have cc'd this
response to the atom-syntax list so that others in the Atom community
can comment.

Comments below.

Thomas Roessler wrote:
> Hi Mike, James, pleased to meet you.
> 
> I'm adding Wendy Seltzer to the CC list, who (I think) might have
> some points to add from a legal perspective.
> 
> Here's the quick review that I did earlier today:
> 
>> - What's the relationship between licensing information contained in
>>  a license-type link and licensing information contained in an
>>  atom:rights element?
> 
> (For the definition of atom:rights, see section 4.2.10 of RFC 4287.)
> 
>>  The example under 2.1 in the I-D suggests that the atom:rights is
>>  expected to reflect the license that is identified in the link
>>  element.  However, there seems to be no machine-readable way to
>>  express that connection.
>>  
>>  Also, there can be multiple license links, but only one rights
>>  element.
>>

This is the third time I've been asked this.  I guess I really do need
to add a clear statement about the relationship in the spec.  With
enough thumps on the head I usually come around ;-)

The relationship is relatively simple.  The atom:rights element is
always a human-readable statement of what rights are held over the feed
or entry.  It's is the equivalent of saying "Copyright (c) James Snell"
and cannot be relied upon to tell the consumer anything useful about
what the consumer can do with the feed or entry.  The license link, on
the other hand, is specifically intended to provide a reference to the
license applied to the feed/entry; that is, what kinds of things others
are allowed do with the feed/entry.

>> - An atom:rights element on a feed sets the default for the
>>  atom:rights elements on entries; a license link on a feed,
>>  however, is expected to apply to the metadata and NOT to the
>>  entries.
>>
>>  Why the difference in inheritance rules and semantics?

This is something that I've debated back and forth on but the difference
comes down to an issue with aggregated feeds.

Take, for instance, Sam Ruby's Planet feed
(http://planet.intertwingly.net/atom.xml).  This feed consists of
entries that originated from many different sources, some of which may
have license links, some that might not.  If Sam decided to put a
license link at the feed level, and if license links were inherited, it
would mean that Sam's license would be extended over resources he may
have no right to license.  Obviously, that's wrong.

One two possible solution would be for Sam to some how indicate that an
entry in his feed did not have a license link, but doing so could cause
other problems (such as invalidating any XML digital signatures that may
be covering the entry).  Also, it's possible that the entry originally
came from a feed that did include a license link, but that some
intermediary along the way failed to properly carry over the license
link into the entry after separating it from the feed.  The bottom line
is that license inheritance opens too many potentially significant
issues. (and yes, these issues apply equally to the atom:rights element).

The simple solution, then, is to specify that license links only cover
the feed or entry containing the link.

>>
>> - It's probably worth noting that there are jurisdictions in which
>>  databases enjoy sui generis legal protection (e.g., the EU).  In
>>  such jurisdictions, it might be reasonable to have license
>>  information that refers to the collection, not just to its
>>  metadata.
>>

The selection and arrangement of entries in the feed is covered by feeds
license.

>> - The following statement:
>>
>>    Entry content might include or reference material from other
>>    sources. Licenses associated with an entry MUST NOT be assumed
>>    to cover such material.  Implementations cannot necessarily
>>    trust that publishers have the right to license material claimed
>>    to be covered by any associated license.  Care should be taken
>>    when making decisions based on the referenced license.
>>
>>  ... takes all of the value out of this scheme.  The very point of
>>  annotating content (even aggregate content) with a license is that
>>  this license be trusted.
> 
> (I understand this to be, in part, a legal layman's overstatement;
> I'll leave it to the lawyers to comment. ;)
> 

Yes, I don't like this either.  But the fact remains that an entries
content may include content from other sources that cannot be assumed to
be covered by the license associated with the entry.  The analogous
situation occurs in Open Source Software distributions in which
dependencies shipped with a project may have their own licenses that are
distinct from the license used for the project code itself.

The question really is whether or not this is worth calling out
explicitly in the spec.

>> Summary: The relationship to atom:rigts should be cleaned up.  The
>> questions above about what precisely a license applies to probably
>> points at a problem in terms of expressivity of the linking scheme
>> -- an argument could be made that there should be machine-readable
>> ways to express what precisely a license link is supposed to apply
>> to. Something like rel={content-license, dataset-license,
>> entry-default-license}?
> 
>> Overall, this document looks like it is in dire need of serious
>> review from legal experts -- e.g., from the Creative Commons
>> community.  

That would be excellent.

> 
> I, too, would be happy to move this discussion to a public mailing
> list.  Is the atompub list the right place to have this
> conversation, or should this go to the IETF plenary, as this draft
> is in IETF Last Call?
> 

The atom-syntax list would be an appropriate forum.

- James




From owner-atom-syntax@mail.imc.org Tue Sep 05 19:14:02 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GKk7G-0004RS-5B
	for atompub-archive@lists.ietf.org; Tue, 05 Sep 2006 19:14:02 -0400
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1GKk7A-0001Qh-Aq
	for atompub-archive@lists.ietf.org; Tue, 05 Sep 2006 19:14:02 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k85MrQi1021519;
	Tue, 5 Sep 2006 15:53:26 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id k85MrQ3F021518;
	Tue, 5 Sep 2006 15:53:26 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.232])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k85MrNnq021494
	for <atom-syntax@imc.org>; Tue, 5 Sep 2006 15:53:26 -0700 (MST)
	(envelope-from jasnell@gmail.com)
Received: by wx-out-0506.google.com with SMTP id t12so2422143wxc
        for <atom-syntax@imc.org>; Tue, 05 Sep 2006 15:53:23 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding;
        b=YEIUCimwTcHCShLFeRXMjqm5GabQbg2IPr9iNNFlAU+1/cKeM8n7Etg8qiSWx0KDAH7BFxz+KCvN5U3XPEJ8YBk8tAOTGVT3N4Y8iGsT9hQvIcAKkJEh74TuLNCsLIFbN6xyfJdDE4O0+Jc7osri6sc21O02AWlWDKcjnvgPQEE=
Received: by 10.70.129.5 with SMTP id b5mr10759573wxd;
        Tue, 05 Sep 2006 15:53:23 -0700 (PDT)
Received: from ?192.168.1.104? ( [67.181.218.96])
        by mx.gmail.com with ESMTP id 29sm3036033wrl.2006.09.05.15.53.21;
        Tue, 05 Sep 2006 15:53:23 -0700 (PDT)
Message-ID: <44FDFFDE.7060304@gmail.com>
Date: Tue, 05 Sep 2006 15:53:18 -0700
From: James M Snell <jasnell@gmail.com>
User-Agent: Thunderbird 1.5.0.5 (X11/20060719)
MIME-Version: 1.0
To: Mike Linksvayer <ml@creativecommons.org>
CC: Thomas Roessler <tlr@w3.org>, Ben Adida <ben@mit.edu>,
        Lisa Dusseault <lisa@osafoundation.org>,
        atom-syntax <atom-syntax@imc.org>
Subject: Re: [cc-tab] *important* heads up
References: <44FD8F55.2010609@mit.edu>	 <1157478767.18377.47.camel@localhost.localdomain> <1157482144.18377.75.camel@localhost.localdomain>
In-Reply-To: <1157482144.18377.75.camel@localhost.localdomain>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
X-Spam-Score: 1.9 (+)
X-Scan-Signature: f2984bf50fb52a9e56055f779793d783


Hey Mike,

Thanks for taking another look.  Comments below.

Mike Linksvayer wrote:
> Hi James,
> 
> The atom license extension was brought to my attention again.  I'm not
> sure what concerns Thomas Roessler (cc'd) has below (I've also cc'd Lisa
> Dusseault as she mentioned the extension to me recently and appears to
> be involved in the process), but upon re-reading the draft I have one.
> I obviously did not read very carefully in the past and must apologize
> for that.
> 
> In any case, the draft says the referenced license only applies to feed
> or entry metadata, not content.  This strikes me as not particularly
> useful and does not match analogous extentions for RSS 1.0 and RSS 2.0:
> 

The difference in semantics is precisely why I'm not using either the
RSS 1.0 or RSS 2.0 extensions for this as I see problems with both the
former approaches.

> http://web.resource.org/rss/1.0/modules/cc/ is RDF, so it is as clear as
> it can be what license annotations apply to, and in the examples they
> apply to the content at the feed (channel) URL (the feed itself) and the
> content at individual entry URLs (content of individual posts).
> 

It is helpful to take a look at the RSS 1.0 rdf:license definition.

From http://web.resource.org/rss/1.0/modules/cc/:

<!-- start -->
  This module aims to give metadata regarding the copyright license
  under which the RSS feed, and the objects it points to, are released
  under.

  [snip]

  <cc:license rdf:resource="URI OF LICENSE" />

  <cc:license rdf:resource=""> can be a sub-element of an RSS item,
  channel or image. The license it refers to is applied to the parent
  element. As with any RDF elements, an occurance of <cc:license> within
  any element implies the copyright of the document contained with the
  rdf:about attribute of that parent element, and not the document
  pointed to by the <link> sub-element.

  The element contains a single rdf:resource attribute which contains
  the URI of the license applied.
<!-- end -->

From this description, and the example that is illustrated in
specification of the rdf:license module, it is evident to me, at least,
that rss 1.0 channels and items are licensed independently from one
another and that an item does not inherit the license of the channel,
otherwise, you could end up with significant problems if two feeds
referenced the same content item with two difference licenses, e.g.

  <rdf:RDF>
    <channel rdf:about="http://example.org/feed1">
      <cc:license rdf:resource="http://example.org/license1" />
      <items>
        <rdf:Seq>
          <rdf:li resource="http://blog.example.com/2006/08/foo" />
        </rdf:Seq>
      </items>
    </channel>
    <item rdf:about="http://blog.example.com/2006/08/foo">
      ...
    </item>
  </rdf:RDF>

  <rdf:RDF>
    <channel rdf:about="http://example.org/feed2">
      <cc:license rdf:resource="http://example.org/license2" />
      <items>
        <rdf:Seq>
          <rdf:li resource="http://blog.example.com/2006/08/foo" />
        </rdf:Seq>
      </items>
    </channel>
    <item rdf:about="http://blog.example.com/2006/08/foo">
      ...
    </item>
  </rdf:RDF>

Because of RDF's data model and the definition of mod_cc, if licenses
are inherited by the items, these two feeds are either making
contradictory claims about the licensing of a single resource, neither
or which the channel publishers may actually have the right to license,
or they are claiming that the resource has been dual-licensed.
Unfortunately, neither claim can be substantiated by looking at the item
itself.

Note that, because of the RDFs data model, the same problem occurs if
the items in each of the above channels each contain their own
contradictory cc:license links.

Further, there is also the problem that the channel element is
describing a different resource that the item element.  The definition
of cc:license says that the license applies to the parent element and
therefore the resource being described by the parent element.  It is not
specified whether or not that license applies to other resources linked
to the channel.

Also, there is a bug in the spec that, in certain situations causes the
spec to contradict itself.  Consider the sentence: "an occurance of
<cc:license> within any element implies the copyright of the document
contained with the rdf:about attribute of that parent element, and not
the document pointed to by the <link> sub-element" then look at the
example given in the spec itself.

  <item rdf:about="http://c.moreover.com/click/here.pl?r123">
    <title>XML: A Disruptive Technology</title>
    <link>http://c.moreover.com/click/here.pl?r123</link>
    <cc:license rdf:resource="..." />
  </item>

The link and the rdf:about attribute point to exactly the same resource,
making the assertion in the spec self-contradictory.


> http://backend.userland.com/creativeCommonsRssModule says license
> annotations apply to the "content of the RSS file" and "content of that
> item", mirroring the RSS 1.0 use.
> 

I do not believe that the RSS 2.0 definition mirrors the RSS 1.0 use.
I've already noted the problems with inherited licenses when
resyndicating entries in aggregated feeds.

> My first thought is that it would be well worth reconsidering the
> semantics of the atom license extension.  My second thought is that you
> must be well aware of the analogous RSS 1.0 and RSS 2.0 modules and did
> not follow their example for a reason.
> 
> I'd appreciate any thoughts you might have on the matter.  If there is a
> public or private list this should be taken to please let me know.
> 
> Mike
> 
> p.s. There is also a problem in non-RDF formats in determining whether
> resources included in entry content (e.g., images) or enclosures are
> licensed.  The mediaRSS module for RSS 2.0 http://search.yahoo.com/mrss
> seems to assume entry license annotations apply to "media" content.
> This is of course messy and probably beyond the scope of the discussion
> above and below.
> 

Linked resources are *not* covered by license links.

- James

> 
> 
>> On Tue, 2006-09-05 at 10:53 -0400, Ben Adida wrote:
>>> Hey all,
>>>
>>> I'm currently busy moving stuff from one office to another, but I have a
>>> feeling this heads-up from Thomas Roessler is worth looking at urgently,
>>> both with tech and legal eyes.
>>>
>>> -Ben
>>>
>>> -------- Original Message --------
>>> Subject: Heads-up: IETF considering license links for ATOM feeds
>>> Date: Tue, 5 Sep 2006 16:10:06 +0200
>>> From: Thomas Roessler <tlr@w3.org>
>>> To: ben@mit.edu
>>> CC: tlr@w3.org
>>>
>>> Hi Ben,
>>>
>>> FYI, the IETF is considering license links for ATOM feeds.
>>>
>>> You might wish to point your colleagues at Creative Commons at this:
>>>
>>>
>>> http://www.ietf.org/internet-drafts/draft-snell-atompub-feed-license-08.txt
>>>
>>> https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=13576&rfc_flag=0
>>>
>>> I understand the draft is in last call until 11 September.
>>>
>>> Reviewing the document, I've stumbled over a number of red flags
>>> (mostly in terms of legal meaning), to the point of possibly being
>>> harmful.
>>>
>>> Regards,




From owner-atom-syntax@mail.imc.org Tue Sep 05 19:30:46 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GKkNS-0000Qu-Jg
	for atompub-archive@lists.ietf.org; Tue, 05 Sep 2006 19:30:46 -0400
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1GKkNR-00045W-5T
	for atompub-archive@lists.ietf.org; Tue, 05 Sep 2006 19:30:46 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k85N8SLJ023519;
	Tue, 5 Sep 2006 16:08:28 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id k85N8S0N023518;
	Tue, 5 Sep 2006 16:08:28 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.237])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k85N8Q2i023510
	for <atom-syntax@imc.org>; Tue, 5 Sep 2006 16:08:27 -0700 (MST)
	(envelope-from jasnell@gmail.com)
Received: by wx-out-0506.google.com with SMTP id t12so2426559wxc
        for <atom-syntax@imc.org>; Tue, 05 Sep 2006 16:08:26 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding;
        b=sQDJMaiaadc6H+Hl+9rDhSj1e6BHwaQDlUHcQyqsXLNNie5uGoZSU7XPn59Qv0Huo+A2SG4rFicIfYCYAL037RiK9lQLI5jQIyQATbvSwFpr6boqdPwwzBpErg66UAqLYWsNWP51z39xpKwmbI8aWPO6LgZnHhDnd5ZRYT0fnQI=
Received: by 10.70.67.4 with SMTP id p4mr8617242wxa;
        Tue, 05 Sep 2006 16:08:26 -0700 (PDT)
Received: from ?192.168.1.104? ( [67.181.218.96])
        by mx.gmail.com with ESMTP id g9sm955472wra.2006.09.05.16.08.24;
        Tue, 05 Sep 2006 16:08:25 -0700 (PDT)
Message-ID: <44FE0365.4010608@gmail.com>
Date: Tue, 05 Sep 2006 16:08:21 -0700
From: James M Snell <jasnell@gmail.com>
User-Agent: Thunderbird 1.5.0.5 (X11/20060719)
MIME-Version: 1.0
To: Wendy Seltzer <wendy@seltzer.org>
CC: Thomas Roessler <tlr@w3.org>, Mike Linksvayer <ml@creativecommons.org>,
        Ben Adida <ben@mit.edu>, Lisa Dusseault <lisa@osafoundation.org>,
        atom-syntax <atom-syntax@imc.org>
Subject: Re: atom license extension (Re: [cc-tab] *important* heads up)
References: <44FD8F55.2010609@mit.edu> <1157478767.18377.47.camel@localhost.localdomain> <1157482144.18377.75.camel@localhost.localdomain> <20060905193613.GX12632@raktajino.does-not-exist.org> <7.0.0.10.2.20060905161932.05e13f08@seltzer.com>
In-Reply-To: <7.0.0.10.2.20060905161932.05e13f08@seltzer.com>
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>
X-Spam-Score: 1.9 (+)
X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86


Hello Wendy,

Thanks for the feedback.  I've cc'd the atom-syntax list so the rest of
the Atom community can comment.

Comments below.

Wendy Seltzer wrote:
> Hi all,
> So my first thoughts upon seeing the draft are to wonder why it's
> necessary to make assertions about the legal effects of including a
> license -- especially since some of those assertions seem to obviate the
> purpose of using a license declaration.   While it's helpful to tell
> people how to indicate, technically, what they mean for a license to
> attach to, it's not useful to offer guidance on how to interpret the
> license.
> 
> Namely:
> 
> 1.1   It must also be noted that licenses associated with feeds or entries
>    using these mechanisms are advisory and are not, by themselves,
>    legally binding.  Nor can a license associated with a feed or entry
>    restrict or forbid access to, redistribution, aggregation, caching
>    and display of those items by third party intermediaries such as
>    search engines and so-called "online aggregators".
> 
> Why can't they be legally binding?  They're not self-executing, but
> licenses outside of feeds aren't either, and likewise may or may not be
> legally binding depending upon other things than just the form of their
> expression.
> 

To this point I've received exactly the opposite feedback from others
(all of whom weren't lawyers, btw, but who have had experience with
licensing issues in the past).

It is my understanding that the licenses cannot be considered legally
binding *by themselves*.  That is, precisely as you indicate, they are
not self-executing.

> 
> 2   "License" link relations appearing within a feed MUST apply to the
>    metadata of the containing feed element only and do not extend over
>    the metadata or content of any contained entries.
> 
> Why? Why would a feed need a license separate from its content?  Lots of
> the metadata elements would be functional or would give users fair use
> claims, absent a license.
> 

Sam Ruby's planet feed is a prime example.  Sam does not own rights over
the individual entries that appear within his feed, however, Sam does
own the rights over the feed itself, including the selection and
arrangement of entries within that feed.

I've mentioned before that it's roughly equivalent to distributing
dependencies with an open source project.  Each of the dependencies have
their own license, distinct from the projects license.

>    Entry content might include or reference material from other sources.
>    Licenses associated with an entry MUST NOT be assumed to cover such
>    material.  Implementations cannot necessarily trust that publishers
>    have the right to license material claimed to be covered by any
>    associated license.  Care should be taken when making decisions based
>    on the referenced license.
> 
> This seems to be going down a road of legal interpretation that's
> unnecessary and not necessarily correct. The current CC licenses are
> offered on a "taker beware" basis -- the licensor offers the rights he
> has, and doesn't guarantee a licensee's rights (or even his own) to
> anything he might have incorporated.  That's not the only way to write a
> license, though.  (Even within CC, version 1 had an explicit
> representation and warranty section that was dropped in v.2.)
> 
> Implementations should trust the legal representations only as much or
> as little as they trust any other claim made by the feed.  How licenses
> chain is a matter of individual legal interpretation.
> 

Ok, so if I'm interpreting this comment correctly, the recommendation
would be to simply remove the paragraph in question?

> 
> Forgive me (but please clarify!) if I'm misinterpreting some of the draft.
> 
> Thanks,
> --Wendy
> 

Thanks for taking the time to review,

- James




From owner-atom-syntax@mail.imc.org Tue Sep 05 19:55:49 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GKklh-0006Wl-O7
	for atompub-archive@lists.ietf.org; Tue, 05 Sep 2006 19:55:49 -0400
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1GKkld-0006Li-7j
	for atompub-archive@lists.ietf.org; Tue, 05 Sep 2006 19:55:49 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k85NetFv027619;
	Tue, 5 Sep 2006 16:40:55 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id k85NetEm027618;
	Tue, 5 Sep 2006 16:40:55 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from ghost.bibliotrack.com (ghost.bibliotrack.com [216.254.98.187])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k85NesNA027603
	for <atom-syntax@imc.org>; Tue, 5 Sep 2006 16:40:54 -0700 (MST)
	(envelope-from wendy@seltzer.com)
Received: from wmstab.seltzer.com (ghost.bibliotrack.com [127.0.0.1])
	by ghost.bibliotrack.com (8.12.8/8.12.8) with ESMTP id k85NdlU7023813
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 5 Sep 2006 19:39:50 -0400
Message-Id: <7.0.0.10.2.20060905191553.064abec0@seltzer.com>
X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.10 (Beta)
Date: Tue, 05 Sep 2006 19:40:24 -0400
To: James M Snell <jasnell@gmail.com>
From: Wendy Seltzer <wendy@seltzer.org>
Subject: Re: atom license extension (Re: [cc-tab] *important* heads up)
Cc: Wendy Seltzer <wendy@seltzer.org>, Thomas Roessler <tlr@w3.org>,
        Mike Linksvayer <ml@creativecommons.org>, Ben Adida <ben@mit.edu>,
        Lisa Dusseault <lisa@osafoundation.org>,
        atom-syntax <atom-syntax@imc.org>
In-Reply-To: <44FE0365.4010608@gmail.com>
References: <44FD8F55.2010609@mit.edu>
 <1157478767.18377.47.camel@localhost.localdomain>
 <1157482144.18377.75.camel@localhost.localdomain>
 <20060905193613.GX12632@raktajino.does-not-exist.org>
 <7.0.0.10.2.20060905161932.05e13f08@seltzer.com>
 <44FE0365.4010608@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>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86


At 04:08 PM 9/5/2006 -0700, James M Snell wrote:
>Hello Wendy,
>
>Thanks for the feedback.  I've cc'd the atom-syntax list so the rest of
>the Atom community can comment.

Thanks James,
I'm still not clear on what's happening in 1.1.

 > 1.1   It must also be noted that licenses associated with feeds or entries
> >    using these mechanisms are advisory and are not, by themselves,
> >    legally binding.  Nor can a license associated with a feed or entry
> >    restrict or forbid access to, redistribution, aggregation, caching
> >    and display of those items by third party intermediaries such as
> >    search engines and so-called "online aggregators".
> >
> > Why can't they be legally binding?  They're not self-executing, but
> > licenses outside of feeds aren't either, and likewise may or may not be
> > legally binding depending upon other things than just the form of their
> > expression.
>
>To this point I've received exactly the opposite feedback from others
>(all of whom weren't lawyers, btw, but who have had experience with
>licensing issues in the past).
>
>It is my understanding that the licenses cannot be considered legally
>binding *by themselves*.  That is, precisely as you indicate, they are
>not self-executing.

What I meant by that is that they don't actively restrict 
non-compliant use, as a technological protection measure does: I can 
receive a feed and choose to breach its license.   They can have 
legal effect, though:  Unless I have some legal excuse such as fair 
use, I'm then not compliant and possibly infringing copyright.  (You 
still have to come after me for copyright infringement.)

Are you trying to say that the license-rel in the feed is merely a 
notification to those who are curious that "this is probably (but 
we're not certain) the license under which the feed may be used" 
?  That's the way it reads.  If so, what's the point?  Don't you 
either want to assert "take the feed under this license or not at 
all" or say nothing and make people come to you and ask?

I'd recommend dropping this paragraph, as it may give incorrect legal advice.

> > 2   "License" link relations appearing within a feed MUST apply to the
> >    metadata of the containing feed element only and do not extend over
> >    the metadata or content of any contained entries.
> >
> > Why? Why would a feed need a license separate from its content?  Lots of
> > the metadata elements would be functional or would give users fair use
> > claims, absent a license.
> >
>Sam Ruby's planet feed is a prime example.  Sam does not own rights over
>the individual entries that appear within his feed, however, Sam does
>own the rights over the feed itself, including the selection and
>arrangement of entries within that feed.

That seems minimally useful to me (the license, not Sam's feed!), but 
why prohibit people from licensing their feeds' content too? Or am I 
just misreading this, and you're saying that depending on where you 
put the tag, the license's coverage differs?

> >    Entry content might include or reference material from other sources.
> >    Licenses associated with an entry MUST NOT be assumed to cover such
> >    material.  Implementations cannot necessarily trust that publishers
> >    have the right to license material claimed to be covered by any
> >    associated license.  Care should be taken when making decisions based
> >    on the referenced license.
> >
> > This seems to be going down a road of legal interpretation that's
> > unnecessary and not necessarily correct. The current CC licenses are
> > offered on a "taker beware" basis -- the licensor offers the rights he
> > has, and doesn't guarantee a licensee's rights (or even his own) to
> > anything he might have incorporated.  That's not the only way to write a
> > license, though.  (Even within CC, version 1 had an explicit
> > representation and warranty section that was dropped in v.2.)
> >
> > Implementations should trust the legal representations only as much or
> > as little as they trust any other claim made by the feed.  How licenses
> > chain is a matter of individual legal interpretation.
> >
>
>Ok, so if I'm interpreting this comment correctly, the recommendation
>would be to simply remove the paragraph in question?

Yes.

Thanks,
--Wendy


-- 
Wendy Seltzer -- wendy@seltzer.com
Visiting Assistant Professor of Law, Brooklyn Law School
Fellow, Berkman Center for Internet & Society
http://cyber.law.harvard.edu/seltzer.html
Chilling Effects: http://www.chillingeffects.org




From owner-atom-syntax@mail.imc.org Tue Sep 05 20:36:48 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GKlPM-0007xt-QG
	for atompub-archive@lists.ietf.org; Tue, 05 Sep 2006 20:36:48 -0400
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1GKlBx-0000WZ-Pb
	for atompub-archive@lists.ietf.org; Tue, 05 Sep 2006 20:22:59 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k8603vFt030744;
	Tue, 5 Sep 2006 17:03:57 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id k8603ulc030743;
	Tue, 5 Sep 2006 17:03:56 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.231])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k8603t1x030736
	for <atom-syntax@imc.org>; Tue, 5 Sep 2006 17:03:56 -0700 (MST)
	(envelope-from jasnell@gmail.com)
Received: by wx-out-0506.google.com with SMTP id t12so2442411wxc
        for <atom-syntax@imc.org>; Tue, 05 Sep 2006 17:03:55 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding;
        b=DEt2vXYX8EJLe8QNdl6qf3Xzk8eLFOeOPH2OLHgME3A1VgwBstEK4piODuko3ebZ9TWBE7yHzRYnzlhNDCJRqqncgborlRoLMZk9/QXEBrBR6TTv8xU/p7fNTlI+mJjXdmL8yoRz5W5+JbaX1G7Do4nE2vWLCmA+cvLaz7KSmII=
Received: by 10.70.38.19 with SMTP id l19mr10896036wxl;
        Tue, 05 Sep 2006 17:03:55 -0700 (PDT)
Received: from ?192.168.1.104? ( [67.181.218.96])
        by mx.gmail.com with ESMTP id 40sm1997943wrl.2006.09.05.17.03.53;
        Tue, 05 Sep 2006 17:03:54 -0700 (PDT)
Message-ID: <44FE1066.2030704@gmail.com>
Date: Tue, 05 Sep 2006 17:03:50 -0700
From: James M Snell <jasnell@gmail.com>
User-Agent: Thunderbird 1.5.0.5 (X11/20060719)
MIME-Version: 1.0
To: Wendy Seltzer <wendy@seltzer.org>
CC: Thomas Roessler <tlr@w3.org>, Mike Linksvayer <ml@creativecommons.org>,
        Ben Adida <ben@mit.edu>, Lisa Dusseault <lisa@osafoundation.org>,
        atom-syntax <atom-syntax@imc.org>
Subject: Re: atom license extension (Re: [cc-tab] *important* heads up)
References: <44FD8F55.2010609@mit.edu> <1157478767.18377.47.camel@localhost.localdomain> <1157482144.18377.75.camel@localhost.localdomain> <20060905193613.GX12632@raktajino.does-not-exist.org> <7.0.0.10.2.20060905161932.05e13f08@seltzer.com> <44FE0365.4010608@gmail.com> <7.0.0.10.2.20060905191553.064abec0@seltzer.com>
In-Reply-To: <7.0.0.10.2.20060905191553.064abec0@seltzer.com>
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>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 25620135586de10c627e3628c432b04a


Comments below.

Wendy Seltzer wrote:
> [snip]
> Thanks James,
> I'm still not clear on what's happening in 1.1.
>
> [snip]
>>
>> To this point I've received exactly the opposite feedback from others
>> (all of whom weren't lawyers, btw, but who have had experience with
>> licensing issues in the past).
>>
>> It is my understanding that the licenses cannot be considered legally
>> binding *by themselves*.  That is, precisely as you indicate, they are
>> not self-executing.
> 
> What I meant by that is that they don't actively restrict non-compliant
> use, as a technological protection measure does: I can receive a feed
> and choose to breach its license.   They can have legal effect, though: 
> Unless I have some legal excuse such as fair use, I'm then not compliant
> and possibly infringing copyright.  (You still have to come after me for
> copyright infringement.)
> 
> Are you trying to say that the license-rel in the feed is merely a
> notification to those who are curious that "this is probably (but we're
> not certain) the license under which the feed may be used" ?  That's the
> way it reads.  If so, what's the point?  Don't you either want to assert
> "take the feed under this license or not at all" or say nothing and make
> people come to you and ask?
> 

What I'm saying is that feed consumers have no guarantee as to who added
the license link to the feed/entry and whether whoever did had the legal
right to do so.  Nor is there any guarantee that license links within a
feed or entry have not been inappropriately modified. Feed publishers
can digitally sign Atom feeds and entries to provide some
non-repudiation protection, but doing so is optional and is not a
guaranteed solution.

> I'd recommend dropping this paragraph, as it may give incorrect legal
> advice.
> 

Ok.

>> > 2   "License" link relations appearing within a feed MUST apply to the
>> >    metadata of the containing feed element only and do not extend over
>> >    the metadata or content of any contained entries.
>> >
>> > Why? Why would a feed need a license separate from its content? 
>> Lots of
>> > the metadata elements would be functional or would give users fair use
>> > claims, absent a license.
>> >
>> Sam Ruby's planet feed is a prime example.  Sam does not own rights over
>> the individual entries that appear within his feed, however, Sam does
>> own the rights over the feed itself, including the selection and
>> arrangement of entries within that feed.
> 
> That seems minimally useful to me (the license, not Sam's feed!), but
> why prohibit people from licensing their feeds' content too? Or am I
> just misreading this, and you're saying that depending on where you put
> the tag, the license's coverage differs?
> 

It's the latter.  The license's coverage differs depending on where it
appears.

>[snip]

- James




From owner-atom-syntax@mail.imc.org Tue Sep 05 21:05:23 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GKlr1-0006Fe-Eo
	for atompub-archive@lists.ietf.org; Tue, 05 Sep 2006 21:05:23 -0400
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1GKlr0-0004xl-19
	for atompub-archive@lists.ietf.org; Tue, 05 Sep 2006 21:05:23 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k860oT0t037449;
	Tue, 5 Sep 2006 17:50:29 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id k860oThL037448;
	Tue, 5 Sep 2006 17:50:29 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.234])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k860oQRB037433
	for <atom-syntax@imc.org>; Tue, 5 Sep 2006 17:50:28 -0700 (MST)
	(envelope-from jasnell@gmail.com)
Received: by wx-out-0506.google.com with SMTP id t12so2455303wxc
        for <atom-syntax@imc.org>; Tue, 05 Sep 2006 17:50:25 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding;
        b=as/NEFW2Oke3rJAVXEKbna1QC1/CkFTzDzwmsLAfZWfdeRE9SP645ULkeGrehX2CsV6JLkpPr9x8dzHtUMUSxOIRiw3VgLsLBJsZbQxE76iczWKlXgbJrkJaUqmdoDEczATRFEMBYf8BAEZnymwFA/sgg64tmRanzsOw+zasTPg=
Received: by 10.70.116.1 with SMTP id o1mr11111822wxc;
        Tue, 05 Sep 2006 17:50:25 -0700 (PDT)
Received: from ?192.168.1.104? ( [67.181.218.96])
        by mx.gmail.com with ESMTP id 44sm262193wri.2006.09.05.17.50.25;
        Tue, 05 Sep 2006 17:50:25 -0700 (PDT)
Message-ID: <44FE1B4C.2010306@gmail.com>
Date: Tue, 05 Sep 2006 17:50:20 -0700
From: James M Snell <jasnell@gmail.com>
User-Agent: Thunderbird 1.5.0.5 (X11/20060719)
MIME-Version: 1.0
To: "Granqvist, Hans" <hgranqvist@verisign.com>
CC: atom-syntax <atom-syntax@imc.org>
Subject: Re: XML Digital Signatures in Atom feeds and entries
References: <45D459DDA07DC442A499A4D46F4939BA02107F00@MOU1WNEXMB02.vcorp.ad.vrsn.com>
In-Reply-To: <45D459DDA07DC442A499A4D46F4939BA02107F00@MOU1WNEXMB02.vcorp.ad.vrsn.com>
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>
X-Spam-Score: 1.9 (+)
X-Scan-Signature: 73734d43604d52d23b3eba644a169745


Thanks Hans,

I've tested Abdera's implementation against the endpoint and the signed
entries validate just fine.  Thanks for having that endpoint up and
running.

For what it's worth, here is how to send a signed ping using Abdera:

  // Initialize the keystore
  KeyStore ks = KeyStore.getInstance(keystoreType);
  InputStream in = Listing11.class.getResourceAsStream(keystoreFile);
  ks.load(in, keystorePass.toCharArray());
  PrivateKey signingKey =
    (PrivateKey) ks.getKey(
      privateKeyAlias,
      privateKeyPass.toCharArray());
  X509Certificate cert =
    (X509Certificate) ks.getCertificate(
      certificateAlias);

  // Create the entry to sign
  Abdera abdera = new Abdera();
  AbderaSecurity absec = new AbderaSecurity(abdera);
  Factory factory = abdera.getFactory();

  Entry entry = factory.newEntry();
  entry.setId("http://example.org/foo/entry");
  entry.setUpdated(new java.util.Date());
  entry.setTitle("This is an entry");
  entry.setContentAsXhtml("This <b>is</b> <i>markup</i>");
  entry.addAuthor("James");
  entry.addLink("http://www.example.org");

  // Prepare the digital signature options
  Signature sig = absec.getSignature();
  SignatureOptions options = sig.getDefaultSignatureOptions();
  options.setCertificate(cert);
  options.setSigningKey(signingKey);

  // Sign the entry
  entry = sig.sign(entry, options);

  // Send the ping
  Client client = new CommonsClient();
  RequestOptions opts = client.getDefaultRequestOptions();
  opts.setContentType("application/xml");
  BaseRequestEntity bre = new BaseRequestEntity(entry,false);
  ClientResponse response = client.post(
    "http://verisignlabs.com/tg/verify", bre, opts);
  if (response.getStatus() == 200) {
    Document<Element> result = response.getDocument();
    writer.writeTo(result, System.out);
  }

- James

Granqvist, Hans wrote:
> James,
> 
> There is an interop service for Atom 1.0 feed/entry signature 
> validation available (with source code for both service and 
> Wordpress plugin) as part of the Signed Ping initiative at 
>   http://signedping.com
> 
> Let me know if you need more info.
> -Hans 
> 
>> -----Original Message-----
>> From: owner-atom-syntax@mail.imc.org 
>> [mailto:owner-atom-syntax@mail.imc.org] On Behalf Of James M Snell
>> Sent: Monday, September 04, 2006 12:02 PM
>> To: atom-syntax
>> Subject: XML Digital Signatures in Atom feeds and entries
>>
>>
>> I'm currently looking for other Atom implementations that 
>> support the option to digitally sign feeds and entries.  
>> Apache Abdera supports digital signatures and encryption and 
>> I'd like to do some interop testing against other impls.
>>
>> - James
>>
>>
>>
> 




From owner-atom-syntax@mail.imc.org Tue Sep 05 22:25:55 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GKn6x-0000HB-2T
	for atompub-archive@lists.ietf.org; Tue, 05 Sep 2006 22:25:55 -0400
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1GKn6s-0000U5-Ee
	for atompub-archive@lists.ietf.org; Tue, 05 Sep 2006 22:25:55 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k8624RRK046290;
	Tue, 5 Sep 2006 19:04:27 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id k8624RRr046289;
	Tue, 5 Sep 2006 19:04:27 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from darwin.ctyme.com (8.ctyme.com [69.50.231.8])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k8624Que046279
	for <atom-syntax@imc.org>; Tue, 5 Sep 2006 19:04:26 -0700 (MST)
	(envelope-from ml@creativecommons.org)
Received: from adsl-75-5-124-98.dsl.pltn13.sbcglobal.net ([75.5.124.98] helo=[192.168.103.16])
	by darwin.ctyme.com with esmtpsa (SSLv3:RC4-MD5:128)
	(Exim 4.62)
	id 1GKmm4-0000cA-FD; Tue, 05 Sep 2006 19:04:20 -0700
Subject: atom liense extension (was Re: [cc-tab] *important* heads up)
From: Mike Linksvayer <ml@creativecommons.org>
To: James M Snell <jasnell@gmail.com>
Cc: Thomas Roessler <tlr@w3.org>, Ben Adida <ben@mit.edu>,
        Lisa Dusseault <lisa@osafoundation.org>,
        atom-syntax <atom-syntax@imc.org>
In-Reply-To: <44FDFFDE.7060304@gmail.com>
References: <44FD8F55.2010609@mit.edu>
	 <1157478767.18377.47.camel@localhost.localdomain>
	 <1157482144.18377.75.camel@localhost.localdomain>
	 <44FDFFDE.7060304@gmail.com>
Content-Type: text/plain
Date: Wed, 06 Sep 2006 02:04:14 +0000
Message-Id: <1157508255.18377.171.camel@localhost.localdomain>
Mime-Version: 1.0
X-Mailer: Evolution 2.6.1 
Content-Transfer-Encoding: 7bit
X-Spamfilter-host: darwin.ctyme.com - http://www.junkemailfilter.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>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f


On Tue, 2006-09-05 at 15:53 -0700, James M Snell wrote:
> Mike Linksvayer wrote:
> > In any case, the draft says the referenced license only applies to feed
> > or entry metadata, not content.  This strikes me as not particularly
> > useful and does not match analogous extentions for RSS 1.0 and RSS 2.0:
>
> The difference in semantics is precisely why I'm not using either the
> RSS 1.0 or RSS 2.0 extensions for this as I see problems with both the
> former approaches.

I understand having problems with RSS 1.0 and RSS 2.0 approaches but I
don't see an inherent and important difference in semantics,
particularly between Atom 1.0 and RSS 2.0.  Of course my vision is
probably foggy. :)

> > http://web.resource.org/rss/1.0/modules/cc/ is RDF, so it is as clear as
> > it can be what license annotations apply to, and in the examples they
> > apply to the content at the feed (channel) URL (the feed itself) and the
> > content at individual entry URLs (content of individual posts). 
> 
> It is helpful to take a look at the RSS 1.0 rdf:license definition.
> 
> >From http://web.resource.org/rss/1.0/modules/cc/:
> 
> <!-- start -->
>   This module aims to give metadata regarding the copyright license
>   under which the RSS feed, and the objects it points to, are released
>   under.
> 
>   [snip]
> 
>   <cc:license rdf:resource="URI OF LICENSE" />
> 
>   <cc:license rdf:resource=""> can be a sub-element of an RSS item,
>   channel or image. The license it refers to is applied to the parent
>   element. As with any RDF elements, an occurance of <cc:license> within
>   any element implies the copyright of the document contained with the
>   rdf:about attribute of that parent element, and not the document
>   pointed to by the <link> sub-element.
> 
>   The element contains a single rdf:resource attribute which contains
>   the URI of the license applied.
> <!-- end -->
> 
> >From this description, and the example that is illustrated in
> specification of the rdf:license module, it is evident to me, at least,
> that rss 1.0 channels and items are licensed independently from one
> another and that an item does not inherit the license of the channel,
> otherwise, you could end up with significant problems if two feeds
> referenced the same content item with two difference licenses, e.g.
> 
>   <rdf:RDF>
>     <channel rdf:about="http://example.org/feed1">
>       <cc:license rdf:resource="http://example.org/license1" />
>       <items>
>         <rdf:Seq>
>           <rdf:li resource="http://blog.example.com/2006/08/foo" />
>         </rdf:Seq>
>       </items>
>     </channel>
>     <item rdf:about="http://blog.example.com/2006/08/foo">
>       ...
>     </item>
>   </rdf:RDF>
> 
>   <rdf:RDF>
>     <channel rdf:about="http://example.org/feed2">
>       <cc:license rdf:resource="http://example.org/license2" />
>       <items>
>         <rdf:Seq>
>           <rdf:li resource="http://blog.example.com/2006/08/foo" />
>         </rdf:Seq>
>       </items>
>     </channel>
>     <item rdf:about="http://blog.example.com/2006/08/foo">
>       ...
>     </item>
>   </rdf:RDF>
> 
> Because of RDF's data model and the definition of mod_cc, if licenses
> are inherited by the items, these two feeds are either making
> contradictory claims about the licensing of a single resource, neither
> or which the channel publishers may actually have the right to license,
> or they are claiming that the resource has been dual-licensed.
> Unfortunately, neither claim can be substantiated by looking at the item
> itself.
> 
> Note that, because of the RDFs data model, the same problem occurs if
> the items in each of the above channels each contain their own
> contradictory cc:license links.
> 
> Further, there is also the problem that the channel element is
> describing a different resource that the item element.  The definition
> of cc:license says that the license applies to the parent element and
> therefore the resource being described by the parent element.  It is not
> specified whether or not that license applies to other resources linked
> to the channel.

The subject of the channel is the feed itself, which necessarily
includes any content delivered with the feed, including the full or
excerpted text of individual items, if delivered with the feed itself.
It is only in this sense that a feed level statement applies to item
content -- when the content is part of the feed.

> Also, there is a bug in the spec that, in certain situations causes the
> spec to contradict itself.  Consider the sentence: "an occurance of
> <cc:license> within any element implies the copyright of the document
> contained with the rdf:about attribute of that parent element, and not
> the document pointed to by the <link> sub-element" then look at the
> example given in the spec itself.
> 
>   <item rdf:about="http://c.moreover.com/click/here.pl?r123">
>     <title>XML: A Disruptive Technology</title>
>     <link>http://c.moreover.com/click/here.pl?r123</link>
>     <cc:license rdf:resource="..." />
>   </item>
> 
> The link and the rdf:about attribute point to exactly the same resource,
> making the assertion in the spec self-contradictory.

The example could be more illustrative but it is hardly contradictory.
AFAICT the item subject (specified by rdf:about) and the link property
usually are the same, indeed the spec
http://web.resource.org/rss/1.0/spec#s5.5 says they "should be
identical ... if possible."  I have no idea why the link property of an
item even exists in RSS 1.0, but that's neither here nor there.

> > http://backend.userland.com/creativeCommonsRssModule says license
> > annotations apply to the "content of the RSS file" and "content of that
> > item", mirroring the RSS 1.0 use.
> > 
> 
> I do not believe that the RSS 2.0 definition mirrors the RSS 1.0 use.

They look as close as they could be to me, given different models (URIs
for feeds and items vs. "content of" feeds and items).  Effectively they
mean the same things.

> I've already noted the problems with inherited licenses when
> resyndicating entries in aggregated feeds.

I agree that assuming entries inherit licenses specified at a feed level
is problematic.  My concern, at the feed and entry level, is that the
atom license extension draft says that a link relation can (only) be
used to associate a license with feed or entry metadata, rather than
content.  Unlike other children of <feed> and <entry> the license
extension is not metadata for the feed or entry but metametadata for the
feed or entry metadata, which strikes me as not particularly useful and
contrary to both RSS 1.0 and RSS 2.0 modules, whatever differences exist
between those.

-- 
  http://wiki.creativecommons.org/User:Mike_Linksvayer




From owner-atom-syntax@mail.imc.org Wed Sep 06 00:05:04 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GKoeu-0007Oy-AW
	for atompub-archive@lists.ietf.org; Wed, 06 Sep 2006 00:05:04 -0400
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1GKoes-0007Nh-TX
	for atompub-archive@lists.ietf.org; Wed, 06 Sep 2006 00:05:04 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k863ou2t061365;
	Tue, 5 Sep 2006 20:50:56 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id k863ouWX061364;
	Tue, 5 Sep 2006 20:50:56 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.230])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k863or1t061356
	for <atom-syntax@imc.org>; Tue, 5 Sep 2006 20:50:56 -0700 (MST)
	(envelope-from jasnell@gmail.com)
Received: by wx-out-0506.google.com with SMTP id t12so2505972wxc
        for <atom-syntax@imc.org>; Tue, 05 Sep 2006 20:50:53 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding;
        b=OLKvJYf/ML1/PMW1NNZRc6NE7IBEclcQteN29tGOhvtyYJY8VgpMleulu/2ZZL0oU4vLIOmKq6lufWCGbG4LkgpNF6/8jvWczhXXe8XsZXdDNpp+MuyRQoJeRjrobZ52bg5nx0elFnRCSsY7CRy2i82A96NO1bgU74m9aRv1g0U=
Received: by 10.70.111.2 with SMTP id j2mr11216146wxc;
        Tue, 05 Sep 2006 20:50:53 -0700 (PDT)
Received: from ?192.168.1.104? ( [67.181.218.96])
        by mx.gmail.com with ESMTP id 64sm7019528wra.2006.09.05.20.50.51;
        Tue, 05 Sep 2006 20:50:53 -0700 (PDT)
Message-ID: <44FE4599.4030707@gmail.com>
Date: Tue, 05 Sep 2006 20:50:49 -0700
From: James M Snell <jasnell@gmail.com>
User-Agent: Thunderbird 1.5.0.5 (X11/20060719)
MIME-Version: 1.0
To: Mike Linksvayer <ml@creativecommons.org>
CC: Thomas Roessler <tlr@w3.org>, Ben Adida <ben@mit.edu>,
        Lisa Dusseault <lisa@osafoundation.org>,
        atom-syntax <atom-syntax@imc.org>
Subject: Re: atom liense extension (was Re: [cc-tab] *important* heads up)
References: <44FD8F55.2010609@mit.edu>	 <1157478767.18377.47.camel@localhost.localdomain>	 <1157482144.18377.75.camel@localhost.localdomain>	 <44FDFFDE.7060304@gmail.com> <1157508255.18377.171.camel@localhost.localdomain>
In-Reply-To: <1157508255.18377.171.camel@localhost.localdomain>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a




Mike Linksvayer wrote:
> On Tue, 2006-09-05 at 15:53 -0700, James M Snell wrote:
>> Mike Linksvayer wrote:
>>> In any case, the draft says the referenced license only applies to feed
>>> or entry metadata, not content.  This strikes me as not particularly
>>> useful and does not match analogous extentions for RSS 1.0 and RSS 2.0:
>> The difference in semantics is precisely why I'm not using either the
>> RSS 1.0 or RSS 2.0 extensions for this as I see problems with both the
>> former approaches.
> 
> I understand having problems with RSS 1.0 and RSS 2.0 approaches but I
> don't see an inherent and important difference in semantics,
> particularly between Atom 1.0 and RSS 2.0.  Of course my vision is
> probably foggy. :)
> 

The difference boils down to one very simple point: contained resources
do not necessarily inherit the license of the container.  The RSS 1.0
and RSS 2.0 modules both assume that the rights holder of the channel
also holds rights over all of the contained items, which works fine when
I'm publishing my own blogs entries in my own feed, but breaks down when
I'm republishing entries from multiple sources.

>[snip]
(I'm still stewing over the bit of comments that I snipped out of this
:-) ...)

> I agree that assuming entries inherit licenses specified at a feed level
> is problematic.  My concern, at the feed and entry level, is that the
> atom license extension draft says that a link relation can (only) be
> used to associate a license with feed or entry metadata, rather than
> content.  Unlike other children of <feed> and <entry> the license
> extension is not metadata for the feed or entry but metametadata for the
> feed or entry metadata, which strikes me as not particularly useful and
> contrary to both RSS 1.0 and RSS 2.0 modules, whatever differences exist
> between those.
> 

My apologies if I haven't been clear on this.  If you look again at
section 1.3, you should find the following:

   For entry elements, "metadata" refers to the values and attributes of
   the author, category, content, contributor, id, link, published,
   rights, source, summary, title, and updated elements, as well as all
   extension elements appearing as children of the entry element and all
   elements appearing as children of the author and contributor
   elements.

Note that the value and attributes of the content, summary, title, etc
elements are all included in entry "metadata".  What isn't covered are
any linked resources.  So any content actually appearing within the
entry is covered by the entry license.

(Note that paragaph 4 of section two will be removed in the next
iteration per Wendy's suggestion)

- James




From owner-atom-syntax@mail.imc.org Wed Sep 06 01:25:26 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GKpug-0002tb-HS
	for atompub-archive@lists.ietf.org; Wed, 06 Sep 2006 01:25:26 -0400
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1GKpuc-0000ho-SQ
	for atompub-archive@lists.ietf.org; Wed, 06 Sep 2006 01:25:26 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k8654svE071200;
	Tue, 5 Sep 2006 22:04:54 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id k8654s9Z071199;
	Tue, 5 Sep 2006 22:04:54 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mcom.com (c3po.aoltw.net [64.236.137.25])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k8654pM9071177
	for <atom-syntax@imc.org>; Tue, 5 Sep 2006 22:04:53 -0700 (MST)
	(envelope-from jpanzer@aol.net)
Received: from [10.169.184.10] (sera-10-169-184-10.nscp.aoltw.net [10.169.184.10])
	by mcom.com (8.10.0/8.10.0) with ESMTP id k8653AW15272;
	Tue, 5 Sep 2006 22:03:10 -0700 (PDT)
Message-ID: <44FE5683.1030509@aol.net>
Date: Tue, 05 Sep 2006 22:02:59 -0700
From: John Panzer <jpanzer@aol.net>
User-Agent: Mozilla Thunderbird 1.0RC1 (Windows/20041201)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: James M Snell <jasnell@gmail.com>
CC: Mike Linksvayer <ml@creativecommons.org>, Thomas Roessler <tlr@w3.org>,
        Ben Adida <ben@mit.edu>, Lisa Dusseault <lisa@osafoundation.org>,
        atom-syntax <atom-syntax@imc.org>, wendy@seltzer.org
Subject: Re: atom liense extension (was Re: [cc-tab] *important* heads up)
References: <44FD8F55.2010609@mit.edu>	 <1157478767.18377.47.camel@localhost.localdomain>	 <1157482144.18377.75.camel@localhost.localdomain>	 <44FDFFDE.7060304@gmail.com> <1157508255.18377.171.camel@localhost.localdomain> <44FE4599.4030707@gmail.com>
In-Reply-To: <44FE4599.4030707@gmail.com>
Content-Type: multipart/alternative;
 boundary="------------000505090601080306090201"
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
X-Spam-Score: 0.6 (/)
X-Scan-Signature: 03fb21b15d5177c512a4caa19876f30a


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

James M Snell wrote:

>
>Mike Linksvayer wrote:
>  
>
>>On Tue, 2006-09-05 at 15:53 -0700, James M Snell wrote:
>>    
>>
>>>Mike Linksvayer wrote:
>>>      
>>>
>>>>In any case, the draft says the referenced license only applies to feed
>>>>or entry metadata, not content.  This strikes me as not particularly
>>>>useful and does not match analogous extentions for RSS 1.0 and RSS 2.0:
>>>>        
>>>>
>>>The difference in semantics is precisely why I'm not using either the
>>>RSS 1.0 or RSS 2.0 extensions for this as I see problems with both the
>>>former approaches.
>>>      
>>>
>>I understand having problems with RSS 1.0 and RSS 2.0 approaches but I
>>don't see an inherent and important difference in semantics,
>>particularly between Atom 1.0 and RSS 2.0.  Of course my vision is
>>probably foggy. :)
>>
>>    
>>
>
>The difference boils down to one very simple point: contained resources
>do not necessarily inherit the license of the container.  The RSS 1.0
>and RSS 2.0 modules both assume that the rights holder of the channel
>also holds rights over all of the contained items, which works fine when
>I'm publishing my own blogs entries in my own feed, but breaks down when
>I'm republishing entries from multiple sources.
>  
>
Here's my rationale:  Atom has explicit support in the core RFC 4287 
syntax  for 'synthetic' feeds containing entries from multiple sources 
produced by multiple authors with different copyrights.  RSS 2.0 doesn't 
have this core support.  So in the case of Atom, the issue is a bit more 
urgent.  So tackling the Atom case first makes sense to me.

(Aside: Is there any reason why an Atom extension couldn't also be used 
as an RSS 2.0 extension too?  In this case, there would be a valid 
reason to add to the already crowded space of license extensions:  
Because it lets you specify the feed license terms separately from the 
individual entry license terms, whereas the other RSS licensing schemes 
don't.)

>  
>
>>[snip]
>>    
>>
>(I'm still stewing over the bit of comments that I snipped out of this
>:-) ...)
>
>  
>
>>I agree that assuming entries inherit licenses specified at a feed level
>>is problematic.  My concern, at the feed and entry level, is that the
>>atom license extension draft says that a link relation can (only) be
>>used to associate a license with feed or entry metadata, rather than
>>content.  Unlike other children of <feed> and <entry> the license
>>extension is not metadata for the feed or entry but metametadata for the
>>feed or entry metadata, which strikes me as not particularly useful and
>>contrary to both RSS 1.0 and RSS 2.0 modules, whatever differences exist
>>between those.
>>
>>    
>>
>
>My apologies if I haven't been clear on this.  If you look again at
>section 1.3, you should find the following:
>
>   For entry elements, "metadata" refers to the values and attributes of
>   the author, category, content, contributor, id, link, published,
>   rights, source, summary, title, and updated elements, as well as all
>   extension elements appearing as children of the entry element and all
>   elements appearing as children of the author and contributor
>   elements.
>
>Note that the value and attributes of the content, summary, title, etc
>elements are all included in entry "metadata".  What isn't covered are
>any linked resources.  So any content actually appearing within the
>entry is covered by the entry license.
>  
>
(Is it just me, or is there too much overloading of "metadata" here?)

Also, does this mean that an entry license would apply to this content:

    <content type="image/gif">TWFuIGlzIGRpc3Rpbmd1aXNoZWQsIG</content>

but not to the same content communicated through an indirect link?

    <content type="image/gif" src="http://example.org/catpicture001.gif"/>

(I'm deliberately picking a GIF picture as I believe there's no good 
solution for embedding license metadata inside GIFs.  )

-John Panzer


--------------000505090601080306090201
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id k8654svE071200

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content=3D"text/html;charset=3DUTF-8" http-equiv=3D"Content-Type"=
>
  <title></title>
</head>
<body bgcolor=3D"#ffffff" text=3D"#000000">
James M Snell wrote:
<blockquote cite=3D"mid44FE4599.4030707@gmail.com" type=3D"cite">
  <pre wrap=3D"">

Mike Linksvayer wrote:
  </pre>
  <blockquote type=3D"cite">
    <pre wrap=3D"">On Tue, 2006-09-05 at 15:53 -0700, James M Snell wrote=
:
    </pre>
    <blockquote type=3D"cite">
      <pre wrap=3D"">Mike Linksvayer wrote:
      </pre>
      <blockquote type=3D"cite">
        <pre wrap=3D"">In any case, the draft says the referenced license=
 only applies to feed
or entry metadata, not content.  This strikes me as not particularly
useful and does not match analogous extentions for RSS 1.0 and RSS 2.0:
        </pre>
      </blockquote>
      <pre wrap=3D"">The difference in semantics is precisely why I'm not=
 using either the
RSS 1.0 or RSS 2.0 extensions for this as I see problems with both the
former approaches.
      </pre>
    </blockquote>
    <pre wrap=3D"">I understand having problems with RSS 1.0 and RSS 2.0 =
approaches but I
don't see an inherent and important difference in semantics,
particularly between Atom 1.0 and RSS 2.0.  Of course my vision is
probably foggy. :)

    </pre>
  </blockquote>
  <pre wrap=3D""><!---->
The difference boils down to one very simple point: contained resources
do not necessarily inherit the license of the container.  The RSS 1.0
and RSS 2.0 modules both assume that the rights holder of the channel
also holds rights over all of the contained items, which works fine when
I'm publishing my own blogs entries in my own feed, but breaks down when
I'm republishing entries from multiple sources.
  </pre>
</blockquote>
Here's my rationale:=C2=A0 Atom has explicit support in the core RFC 4287
syntax=C2=A0 for 'synthetic' feeds containing entries from multiple sourc=
es
produced by multiple authors with different copyrights.=C2=A0 RSS 2.0
doesn't have this core support.=C2=A0 So in the case of Atom, the issue i=
s a
bit more urgent.=C2=A0 So tackling the Atom case first makes sense to me.=
<br>
<br>
(Aside: Is there any reason why an Atom extension couldn't also be used
as an RSS 2.0 extension too?=C2=A0 In this case, there would be a valid
reason to add to the already crowded space of license extensions:=C2=A0
Because it lets you specify the feed license terms separately from the
individual entry license terms, whereas the other RSS licensing schemes
don't.)<br>
<br>
<blockquote cite=3D"mid44FE4599.4030707@gmail.com" type=3D"cite">
  <pre wrap=3D"">
  </pre>
  <blockquote type=3D"cite">
    <pre wrap=3D"">[snip]
    </pre>
  </blockquote>
  <pre wrap=3D""><!---->(I'm still stewing over the bit of comments that =
I snipped out of this
:-) ...)

  </pre>
  <blockquote type=3D"cite">
    <pre wrap=3D"">I agree that assuming entries inherit licenses specifi=
ed at a feed level
is problematic.  My concern, at the feed and entry level, is that the
atom license extension draft says that a link relation can (only) be
used to associate a license with feed or entry metadata, rather than
content.  Unlike other children of &lt;feed&gt; and &lt;entry&gt; the lic=
ense
extension is not metadata for the feed or entry but metametadata for the
feed or entry metadata, which strikes me as not particularly useful and
contrary to both RSS 1.0 and RSS 2.0 modules, whatever differences exist
between those.

    </pre>
  </blockquote>
  <pre wrap=3D""><!---->
My apologies if I haven't been clear on this.  If you look again at
section 1.3, you should find the following:

   For entry elements, "metadata" refers to the values and attributes of
   the author, category, content, contributor, id, link, published,
   rights, source, summary, title, and updated elements, as well as all
   extension elements appearing as children of the entry element and all
   elements appearing as children of the author and contributor
   elements.

Note that the value and attributes of the content, summary, title, etc
elements are all included in entry "metadata".  What isn't covered are
any linked resources.  So any content actually appearing within the
entry is covered by the entry license.
  </pre>
</blockquote>
(Is it just me, or is there too much overloading of "metadata" here?)<br>
<br>
Also, does this mean that an entry license would apply to this content:<b=
r>
<br>
=C2=A0=C2=A0=C2=A0 &lt;content
type=3D"image/gif"&gt;TWFuIGlzIGRpc3Rpbmd1aXNoZWQsIG&lt;/content&gt;<br>
<br>
but not to the same content communicated through an indirect link?<br>
<br>
=C2=A0=C2=A0=C2=A0 &lt;content type=3D"image/gif"
src=3D<a class=3D"moz-txt-link-rfc2396E" href=3D"http://example.org/catpi=
cture001.gif">"http://example.org/catpicture001.gif"</a>/&gt;<br>
<br>
(I'm deliberately picking a GIF picture as I believe there's no good
solution for embedding license metadata inside GIFs.=C2=A0 )<br>
<br>
-John Panzer<br>
<br>
</body>
</html>

--------------000505090601080306090201--




From owner-atom-syntax@mail.imc.org Wed Sep 06 02:27:10 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GKqsQ-0001Rx-30
	for atompub-archive@lists.ietf.org; Wed, 06 Sep 2006 02:27:10 -0400
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1GKqsM-00087H-N4
	for atompub-archive@lists.ietf.org; Wed, 06 Sep 2006 02:27:10 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k866AwdP080079;
	Tue, 5 Sep 2006 23:10:58 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id k866Aw0Q080078;
	Tue, 5 Sep 2006 23:10:58 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.239])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k866AtkT080071
	for <atom-syntax@imc.org>; Tue, 5 Sep 2006 23:10:57 -0700 (MST)
	(envelope-from jasnell@gmail.com)
Received: by wx-out-0506.google.com with SMTP id t12so2541641wxc
        for <atom-syntax@imc.org>; Tue, 05 Sep 2006 23:10:54 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding;
        b=YOJLcqtYpkuCDW87SN0Y1V3FsYzKE1lGHhUqCu7uqcqLWcvgH6woBNrpqj+V8gnBZu2GkHqraNo9GMAt+aV3BxftbDtwXYiL8ON5EcZzOQmRgadESAu6f/hX86WywXAQ73GAIY7Fh/9n/83Jhva+uLNbl3w3i9vK2oE/arfJ2x0=
Received: by 10.70.9.4 with SMTP id 4mr12610074wxi;
        Tue, 05 Sep 2006 23:10:54 -0700 (PDT)
Received: from ?192.168.1.104? ( [67.181.218.96])
        by mx.gmail.com with ESMTP id 14sm242318wrl.2006.09.05.23.10.53;
        Tue, 05 Sep 2006 23:10:54 -0700 (PDT)
Message-ID: <44FE666A.5060300@gmail.com>
Date: Tue, 05 Sep 2006 23:10:50 -0700
From: James M Snell <jasnell@gmail.com>
User-Agent: Thunderbird 1.5.0.5 (X11/20060719)
MIME-Version: 1.0
To: John Panzer <jpanzer@aol.net>
CC: Mike Linksvayer <ml@creativecommons.org>, Thomas Roessler <tlr@w3.org>,
        Ben Adida <ben@mit.edu>, Lisa Dusseault <lisa@osafoundation.org>,
        atom-syntax <atom-syntax@imc.org>, wendy@seltzer.org
Subject: Re: atom liense extension (was Re: [cc-tab] *important* heads up)
References: <44FD8F55.2010609@mit.edu>	 <1157478767.18377.47.camel@localhost.localdomain>	 <1157482144.18377.75.camel@localhost.localdomain>	 <44FDFFDE.7060304@gmail.com> <1157508255.18377.171.camel@localhost.localdomain> <44FE4599.4030707@gmail.com> <44FE5683.1030509@aol.net>
In-Reply-To: <44FE5683.1030509@aol.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32


Yes, that's what it means, which I'll definitely admit is odd.  I think
there is a massive gray area here that needs to be worked out.  I'm not
sure how to work it out.

- James

John Panzer wrote:
>[snip]
> (Is it just me, or is there too much overloading of "metadata" here?)
> 
> Also, does this mean that an entry license would apply to this content:
> 
>     <content type="image/gif">TWFuIGlzIGRpc3Rpbmd1aXNoZWQsIG</content>
> 
> but not to the same content communicated through an indirect link?
> 
>     <content type="image/gif" src="http://example.org/catpicture001.gif"/>
> 
> (I'm deliberately picking a GIF picture as I believe there's no good
> solution for embedding license metadata inside GIFs.  )
> 
> -John Panzer
> 




From owner-atom-syntax@mail.imc.org Wed Sep 06 02:51:27 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GKrFv-0007Mw-Rj
	for atompub-archive@lists.ietf.org; Wed, 06 Sep 2006 02:51:27 -0400
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1GKrFv-0003zN-61
	for atompub-archive@lists.ietf.org; Wed, 06 Sep 2006 02:51:27 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k866PwcT082068;
	Tue, 5 Sep 2006 23:25:58 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id k866PwgL082067;
	Tue, 5 Sep 2006 23:25:58 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from omr8.networksolutionsemail.com (omr8.networksolutionsemail.com [205.178.146.58])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k866PvX6082061
	for <atom-syntax@imc.org>; Tue, 5 Sep 2006 23:25:58 -0700 (MST)
	(envelope-from bob@wyman.us)
Received: from mail.networksolutionsemail.com (ns-omr8.mgt.netsol.com [10.49.6.71])
	by omr8.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id k866PupV028589
	for <atom-syntax@imc.org>; Wed, 6 Sep 2006 02:25:56 -0400
Received: (qmail 2151 invoked by uid 78); 6 Sep 2006 06:25:55 -0000
Received: from unknown (HELO BOBSLAPTOP) (69.201.178.152)
  by ns-omr8.lb.hosting.dc2.netsol.com with SMTP; 6 Sep 2006 06:25:55 -0000
From: "Bob Wyman" <bob@wyman.us>
To: "'Wendy Seltzer'" <wendy@seltzer.org>,
        "'James M Snell'" <jasnell@gmail.com>
Cc: "'Thomas Roessler'" <tlr@w3.org>,
        "'Mike Linksvayer'" <ml@creativecommons.org>,
        "'Ben Adida'" <ben@mit.edu>,
        "'Lisa Dusseault'" <lisa@osafoundation.org>,
        "'atom-syntax'" <atom-syntax@imc.org>
Subject: RE: atom license extension (Re: [cc-tab] *important* heads up)
Date: Wed, 6 Sep 2006 02:25:47 -0400
Message-ID: <006f01c6d17d$4a91bca0$6400a8c0@BOBSLAPTOP>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962
Thread-Index: AcbRSSy8lAEX3mfnQ42xZRB06Cb2OgAJB/tQ
In-Reply-To: <7.0.0.10.2.20060905191553.064abec0@seltzer.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>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21


Wendy Seltzer wrote:
> I'm still not clear on what's happening in 1.1.
>> 1.1  It must also be noted that licenses associated with
>> feeds or entries using these mechanisms are advisory and
>> are not, by themselves, legally binding.  
	Section 1.1 contains two sentences that are, I think, at least in
part the result of a telephone conversation on this subject that James and I
had about a week ago. However, I think that James has written both sentences
too strongly and it is quite possible the first sentence is unnecessary.
I'll explain the logic behind my reasoning. First, the first sentence and
the second, later.
	The first sentence is concerned with the binding between the feed or
entry and the actual license. For one to rely on a license, either as a
rights holder or as a grantee, you need to be able to show what the license
actually said at the time that you relied upon it.
	Because of the nature of the tool being used here, a hyperlink, we
must accept that the binding between content and license is a weak and
fragile one. There is no guarantee that the content of the license
associated with a feed at one instance will be the same as it is at some
other instance. Also, there is no mechanism provided to ensure that claims
made about what the license was at one instance can be proved at a later
time. This weakness of the link is going to make it very difficult for
either a copyright holder or one who relies on a license found in a license
link to rely on being able to make definitive statements about what the
license content actually was. Certainly, there are special cases. For
instance, those who link to Creative Commons licenses using the appropriate
and presumably well managed URLs that Creative Commons provides are going to
be able to much more certain when making assertions about license content
since these licenses are only modified in very public and dated events.
However, Creative Commons is a special case and can't be generalized to all
possible licenses. Thus, while we might find that links to Creative Commons
licenses (and others which are similarly well managed) might be effective,
it is likely that links to at least some other licenses would not be
considered effective. Thus, it might be better to word the sentence
conditionally. Something like: "licenses associated with feeds or entries
using these mechanisms may not be legally binding"...
	My personal feeling is that given the customs of the net today, it
is likely that the most common licenses referred to in these links will, in
fact, be Creative Commons licenses which grant rights otherwise restricted
by copyright. The problems come in licenses which attempt to restrict
rights. One class of such licenses will be those that claim rights that are
already reserved under copyright. Such licenses are really redundant and
don't accomplish anything useful. I'll ignore those for now. The most
interesting cases will be those licenses that attempt to assert limitations
to rights which would normally be considered to be granted to consumers of
feeds. Such rights would include things like "Fair Use" and "implied
licenses." It is *vitally* important to our community that we ensure that
such restrictive licenses are not encouraged or facilitated by this rfc.
	There are those, I among them, who argue that the mere act of
encoding data in a syndication format such as RSS or Atom, posting that
content on an openly accessible web site, and doing such things as pinging
to publicize the presence of that content, creates a limited "implied
license" for others to access and copy the data for the purposes of
syndication. This is very much like the implied license to copy HTML into
system buffers, caches, network routers, local disks etc in the process of
reading it. With HTML, courts appear to accept that you have a right to do
something that would be prohibited by a strict reading of copyright law.
Under limited circumstances, you are allowed to make copies that are
technically necessary and facilitative to the achievement of the content
creator's assumed purpose of having you read the pages. Similarly, when you
publish to a syndication network, one accepts that there is an implied
license to do not only the same kind of copying that is permitted for HTML,
but also that you accept that your content will be processed by various
syndication-related intermediaries -- feed aggregators, feed filters, feed
format converters, publish/subscribe systems, etc. However, please note that
this is still a *limited* implied license. The fact that syndication is
permitted doesn't mean that the general creation of derivative works,
repurposing of feed content, etc. is permitted. The license doesn't allow
"stealing" -- it only allows moving the stuff around in the process of
getting it to readers.
	The syndication network can only work because we assume that there
is an implied right to syndicate. If, for some reason, we were to establish
that this implied right could be revoked or modified by licenses associated
with a feed or entry, then we'd probably have to shutdown the entire
syndication network until such time as every intermediary and aggregator was
modified to support license discovery and interpretation. The social and
economic cost of this destruction of one of the most exciting areas of
innovation on the net today would simply not be accepted by the courts -- at
least not in the USA (I believe). Courts aren't going to accept this
"poisoning of the stream" simply so that someone can commandeer the
syndication network and force it to process data in a manner different from
the way it was designed to work.
	Of course, one could argue that as long as the Atom license link was
used by everyone, then it should be easy for folk to make the adjustments
and thus the cost might not be too great. However, once we've accepted that
there is even one mechanism by which someone can publish content that
overrides the implied license to syndicate, we must ask the question: "In
how many ways can the override be expressed?" As far as the law is
concerned, there is nothing special about IETF standards. Thus, while the
IETF might say that you can use a license link to bind content and licenses,
the W3C might decide to create a "rights" link instead. ANSI might then
create a "copyright-assertion" link. And someone else might decide to use an
element instead of a link. The problem here is that operators of syndication
components and aggregators would have no means of being sure that they were
catching all the licenses associated with the feeds that they were
syndicating. Someone who was malicious might, in fact, create a new
"standard," publish content with a restrictive license, and then make a
bundle by suing everyone downstream. 
	I think courts won't permit a situation in which the consumer of
content has no idea how to determine if licenses are associated with content
in the same way that they don't let you rely on "Do not enter" signs written
in tiny, unreadable type. The courts would probably insist that legislatures
do as they did with the copyright symbol -- make a formal, legal
determination of how licenses are to be linked to. (Let's hope that we don't
get legislatures involved in the definition of Atom. We've got enough issues
to deal with already.)
	In any case, it may be that "Ignorance of the law is no excuse!"
however, ignorance of an optional, experimental extension to the Atom format
is certainly not a crime. No matter how earnestly content creators may be in
wanting to use the license link to restrict rights, they have no means of
compelling anyone to pay attention to or even take note of the links... Even
in the case of some system that can be shown to understand the license link
mechanism, it can be argued that in the absence of a legally accepted syntax
for stating restrictions on rights, that the reader can't compelled to
"understand" the limitations expressed. (Note: let's not talk about creating
a machine readable license format... Just about all useful methods of doing
so are already patented...)
	In summary:
	1. It is unwise to induce folk into believing that the license link
can be used to override the limited implied license to syndicate, and
	2. There is no way to compel anyone to take note of the links
anyway.
	The situation is, of course, different with things like Creative
Commons licenses. Courts are likely to say that any publisher who includes
the appropriate namespaces in their feeds and includes properly formatted
license links that point to Creative Commons licenses is demonstrating a
real knowledge and appreciation of the mechanism and is willingly granting
licenses to all those who share the same understanding of the mechanism and
willingness to use it. Basically, the publisher proves, by making the effort
and signaling via the published and controlled syntax, that they do, in
fact, wish to grant the rights expressed in the license. Readers of feeds
are then free to exploit their understanding of the publisher's signals to
exercise the rights granted -- just as they are free to refuse to understand
the restrictive licenses published by others.
	Thus, it would seem that the only effective use of the license link
is to grant rights not to restrict them.

The second sentence in 1.1 is:
>> Nor can a license associated with a feed or entry
>> restrict or forbid access to, redistribution, aggregation,
>> caching and display of those items by third party
>> intermediaries such as search engines and so-called
>> "online aggregators".
	This second part of 1.1 is stating support for the theory that the
act of publishing data in the Atom format creates an "implied license" for
the limited purpose of syndication and lists a number of processes which are
considered to be part of the syndication process. Hopefully, my discussion
of the first sentence explains what this is all about.
	My only suggestion for this sentence is that it might be less
strongly worded. Given that the law in this area is not settled, it might
make sense not to say "Nor can a license... restrict..." Rather, it might be
more accurate to say something like: "It is believed that a license ...
cannot restrict...."

	My apologies for such a long message...

	bob wyman





From owner-atom-syntax@mail.imc.org Wed Sep 06 05:24:16 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GKtdo-0002lL-CV
	for atompub-archive@lists.ietf.org; Wed, 06 Sep 2006 05:24:16 -0400
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1GKtdl-0007qz-D3
	for atompub-archive@lists.ietf.org; Wed, 06 Sep 2006 05:24:16 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k8692IxP007756;
	Wed, 6 Sep 2006 02:02:18 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id k8692IgL007755;
	Wed, 6 Sep 2006 02:02:18 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from kamino.does-not-exist.org (kamino.does-not-exist.org [217.160.221.198])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k8692GNP007748
	for <atom-syntax@imc.org>; Wed, 6 Sep 2006 02:02:17 -0700 (MST)
	(envelope-from roessler@does-not-exist.org)
Received: from raktajino.does-not-exist.org (ip-83-99-50-11.dyn.luxdsl.pt.lu [83.99.50.11])
	(using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits))
	(No client certificate requested)
	by kamino.does-not-exist.org (Postfix) with ESMTP
	id E70B4193661; Wed,  6 Sep 2006 11:02:14 +0200 (CEST)
Received: from roessler by raktajino.does-not-exist.org with local (Exim 4.62)
	(envelope-from <roessler@does-not-exist.org>)
	id 1GKtIT-0005Rv-BM; Wed, 06 Sep 2006 11:02:13 +0200
Date: Wed, 6 Sep 2006 11:02:12 +0200
From: Thomas Roessler <roessler@does-not-exist.org>
To: Bob Wyman <bob@wyman.us>
Cc: "'Wendy Seltzer'" <wendy@seltzer.org>,
        "'James M Snell'" <jasnell@gmail.com>,
        "'Mike Linksvayer'" <ml@creativecommons.org>,
        "'Ben Adida'" <ben@mit.edu>,
        "'Lisa Dusseault'" <lisa@osafoundation.org>,
        "'atom-syntax'" <atom-syntax@imc.org>
Subject: Re: atom license extension (Re: [cc-tab] *important* heads up)
Message-ID: <20060906090212.GM12632@raktajino.does-not-exist.org>
Mail-Followup-To: Bob Wyman <bob@wyman.us>,
	'Wendy Seltzer' <wendy@seltzer.org>,
	'James M Snell' <jasnell@gmail.com>,
	'Mike Linksvayer' <ml@creativecommons.org>,
	'Ben Adida' <ben@mit.edu>, 'Lisa Dusseault' <lisa@osafoundation.org>,
	'atom-syntax' <atom-syntax@imc.org>
References: <7.0.0.10.2.20060905191553.064abec0@seltzer.com> <006f01c6d17d$4a91bca0$6400a8c0@BOBSLAPTOP>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <006f01c6d17d$4a91bca0$6400a8c0@BOBSLAPTOP>
User-Agent: Mutt/1.5.13 (2006-09-01)
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d


On 2006-09-06 02:25:47 -0400, Bob Wyman wrote:

> 	Because of the nature of the tool being used here, a
> hyperlink, we must accept that the binding between content and
> license is a weak and fragile one. There is no guarantee that the
> content of the license associated with a feed at one instance
> will be the same as it is at some other instance. Also, there is
> no mechanism provided to ensure that claims made about what the
> license was at one instance can be proved at a later time.

I think this assessment mixes two aspects: The use of the
rel=license link as an *identifier* for a specific license (which is
pretty much what Creative Commons does), and the use of the link to
retrieve license information.

The value that this specification adds to Atom is mostly in the
"link-as-identifier" field: It enables software to offer, e.g.,
retrieval of feeds (or entries) by license.  Look at the Creative
Commons powered aspects of flickr search for a related example.  

Trying to dilute the value of the license link out of fear that the
link-as-retrieval-mechanism aspect is dangerous, however, impacts
the value of the link-as-identifier aspect. As you point out, the
weakness of the link between content and a specific license (in the
sense of legal code) causes problems for both the copyright holder
and the relying party.  A corollary of this is that, in fact, both
sides have an incentive to use licenses that are identified by a
stable URI.

Hence, I'd suggest that, in making balancing decisions for this
specification, emphasis be put on using URIs as *identifiers* for
licenses.  It's fine to point out the lack of an enforceable binding
on a technical level, but I don't think this spec is the place to
discuss the legal implications that this might have.

-- 
Thomas Roessler   <roessler@does-not-exist.org>




From owner-atom-syntax@mail.imc.org Wed Sep 06 05:55:12 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GKu7k-0003E8-AX
	for atompub-archive@lists.ietf.org; Wed, 06 Sep 2006 05:55:12 -0400
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1GKu7h-000501-MX
	for atompub-archive@lists.ietf.org; Wed, 06 Sep 2006 05:55:12 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k869SqJv011545;
	Wed, 6 Sep 2006 02:28:52 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id k869SqB7011544;
	Wed, 6 Sep 2006 02:28:52 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from kamino.does-not-exist.org (kamino.does-not-exist.org [217.160.221.198])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k869SoDU011536
	for <atom-syntax@imc.org>; Wed, 6 Sep 2006 02:28:50 -0700 (MST)
	(envelope-from roessler@does-not-exist.org)
Received: from raktajino.does-not-exist.org (ip-83-99-50-11.dyn.luxdsl.pt.lu [83.99.50.11])
	(using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits))
	(No client certificate requested)
	by kamino.does-not-exist.org (Postfix) with ESMTP
	id 099841936D8; Wed,  6 Sep 2006 11:28:49 +0200 (CEST)
Received: from roessler by raktajino.does-not-exist.org with local (Exim 4.62)
	(envelope-from <roessler@does-not-exist.org>)
	id 1GKtiB-0005SJ-St; Wed, 06 Sep 2006 11:28:47 +0200
Date: Wed, 6 Sep 2006 11:28:47 +0200
From: Thomas Roessler <roessler@does-not-exist.org>
To: James M Snell <jasnell@gmail.com>
Cc: Mike Linksvayer <ml@creativecommons.org>, Ben Adida <ben@mit.edu>,
        Lisa Dusseault <lisa@osafoundation.org>, wendy@seltzer.org,
        atom-syntax <atom-syntax@imc.org>
Subject: Re: atom license extension (Re: [cc-tab] *important* heads up)
Message-ID: <20060906092847.GN12632@raktajino.does-not-exist.org>
Mail-Followup-To: James M Snell <jasnell@gmail.com>,
	Mike Linksvayer <ml@creativecommons.org>, Ben Adida <ben@mit.edu>,
	Lisa Dusseault <lisa@osafoundation.org>, wendy@seltzer.org,
	atom-syntax <atom-syntax@imc.org>
References: <44FD8F55.2010609@mit.edu> <1157478767.18377.47.camel@localhost.localdomain> <1157482144.18377.75.camel@localhost.localdomain> <20060905193613.GX12632@raktajino.does-not-exist.org> <44FDF60A.1010508@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <44FDF60A.1010508@gmail.com>
User-Agent: Mutt/1.5.13 (2006-09-01)
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k869SpDU011539
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21


On 2006-09-05 15:11:22 -0700, James M Snell wrote:

> The relationship is relatively simple.  The atom:rights element
> is always a human-readable statement of what rights are held over
> the feed or entry.  It's is the equivalent of saying "Copyright
> (c) James Snell" and cannot be relied upon to tell the consumer
> anything useful about what the consumer can do with the feed or
> entry.  The license link, on the other hand, is specifically
> intended to provide a reference to the license applied to the
> feed/entry; that is, what kinds of things others are allowed do
> with the feed/entry.

Well, the definition of the atom:rights field is really just another
way to describe what a license is. Namely, the law gives you certain
rights that you, and only you, can exercise.  A license is about
which of these rights you retain, and which ones you let others
exercise.

The example in section 2 of draft-snell-atompub-feed-license-08
actually uses the atom:rights field for indicating which license
applies.

How would that mix with a license link that points at another
Creative Commons License?  And what effect does that have for, say,
license-based search engines?

I don't think the spec can wriggle out of this by saying that the
two aren't entirely the same and maybe shouldn't conflict.

> >> - An atom:rights element on a feed sets the default for the
> >>  atom:rights elements on entries; a license link on a feed,
> >>  however, is expected to apply to the metadata and NOT to the
> >>  entries.

> >>  Why the difference in inheritance rules and semantics?

> This is something that I've debated back and forth on but the difference
> comes down to an issue with aggregated feeds.
> 
> Take, for instance, Sam Ruby's Planet feed
> (http://planet.intertwingly.net/atom.xml).  This feed consists of
> entries that originated from many different sources, some of which may
> have license links, some that might not.  If Sam decided to put a
> license link at the feed level, and if license links were inherited, it
> would mean that Sam's license would be extended over resources he may
> have no right to license.  Obviously, that's wrong.

Obviously, that's not obvious.  Who are we to tell that Sam hasn't
obtained the right to attach these licenses out-of-band?

> One two possible solution would be for Sam to some how indicate
> that an entry in his feed did not have a license link, but doing
> so could cause other problems (such as invalidating any XML
> digital signatures that may be covering the entry).  

> Also, it's possible that the entry originally came from a feed
> that did include a license link, but that some intermediary along
> the way failed to properly carry over the license link into the
> entry after separating it from the feed.  The bottom line is that
> license inheritance opens too many potentially significant
> issues. (and yes, these issues apply equally to the atom:rights
> element).

> The simple solution, then, is to specify that license links only
> cover the feed or entry containing the link.

I don't think this spec needs to deal with the case that license
links might be altered by intermediaries.  It's fine to mention that
in the Security Considerations section, but I don't think it's a
case that should influence the overall design.

In Atom, we so far have an atom:rights entry that describes licenses
on entries.  Either, it sets a default (with all the problems that
you describe), or, it sets the rights for a specific entry.  In what
way this gets used (and whether that use is the right one) is up to
the party that authors an entry or a feed.

The rel=license proposal moves away from this approach:  The
semantics here are that it makes a statement about whatever object
it is attached to -- either a feed (with peculiar semantics that
might quite well depend on the jurisdiction), or to entries that are
children of that feed.

This inconsistency is a recipe for confusion.

In the interest of consistency, I'd suggest to replicate the
semantics of atom:rights for whatever URI-based scheme is
introduced.  If there's a need for feed-level licenses, then that
should be marked up separately. (I can see use cases for that, see
below; I'm not sure it's something urgent.)

> >> - It's probably worth noting that there are jurisdictions in which
> >>  databases enjoy sui generis legal protection (e.g., the EU).  In
> >>  such jurisdictions, it might be reasonable to have license
> >>  information that refers to the collection, not just to its
> >>  metadata.

> The selection and arrangement of entries in the feed is covered by feeds
> license.

From draft-snell-atompub-feed-license-08:

   "License" link relations appearing within a feed MUST apply to
   the metadata of the containing feed element only and do not
   extend over the metadata or content of any contained entries.

I don't see the selection and arrangement in there.

It might be best to focus on licenses on entries for the moment, and
do licenses for metadata, selections and arrangements separately, if
at all.

> >> - The following statement:
> >>
> >>    Entry content might include or reference material from other
> >>    sources. Licenses associated with an entry MUST NOT be assumed
> >>    to cover such material.  Implementations cannot necessarily
> >>    trust that publishers have the right to license material claimed
> >>    to be covered by any associated license.  Care should be taken
> >>    when making decisions based on the referenced license.
> >>
> >>  ... takes all of the value out of this scheme.  The very point of
> >>  annotating content (even aggregate content) with a license is that
> >>  this license be trusted.
> > 
> > (I understand this to be, in part, a legal layman's overstatement;
> > I'll leave it to the lawyers to comment. ;)
> > 
> 
> Yes, I don't like this either.  But the fact remains that an entries
> content may include content from other sources that cannot be assumed to
> be covered by the license associated with the entry.  The analogous
> situation occurs in Open Source Software distributions in which
> dependencies shipped with a project may have their own licenses that are
> distinct from the license used for the project code itself.
> 
> The question really is whether or not this is worth calling out
> explicitly in the spec.

I'll give a +1 to Wendy's suggestion to just drop this.


There's one more point that the spec might need to drill down on: It
is not clear to me whether atom:rights -- or rel=license, for that
matter -- applies to the material in an entry [ultimately, metadata
about a resource], or to the (in Atom speak) alternative versions
[the resource that the entry is about, in RDF speak].  This probably
doesn't matter too much for blog data; it likely does matter in
other contexts.

I'd hope that I'm missing some point, but quite possibly there needs
to be an explicit decision here whether the license link is expected
to apply only to the material in the entry, or to the "alternative
versions" [resources the entry is about] as well.  

Regards,
-- 
Thomas Roessler   <roessler@does-not-exist.org>




From owner-atom-syntax@mail.imc.org Wed Sep 06 05:57:58 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GKuAQ-0003pK-1q
	for atompub-archive@lists.ietf.org; Wed, 06 Sep 2006 05:57:58 -0400
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1GKuAO-0005WC-Ml
	for atompub-archive@lists.ietf.org; Wed, 06 Sep 2006 05:57:58 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k869auEk013398;
	Wed, 6 Sep 2006 02:36:56 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id k869auM8013396;
	Wed, 6 Sep 2006 02:36:56 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from kamino.does-not-exist.org (kamino.does-not-exist.org [217.160.221.198])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k869atPH013374
	for <atom-syntax@imc.org>; Wed, 6 Sep 2006 02:36:56 -0700 (MST)
	(envelope-from roessler@does-not-exist.org)
Received: from raktajino.does-not-exist.org (ip-83-99-50-11.dyn.luxdsl.pt.lu [83.99.50.11])
	(using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits))
	(No client certificate requested)
	by kamino.does-not-exist.org (Postfix) with ESMTP
	id 89A90193661; Wed,  6 Sep 2006 11:36:54 +0200 (CEST)
Received: from roessler by raktajino.does-not-exist.org with local (Exim 4.62)
	(envelope-from <roessler@does-not-exist.org>)
	id 1GKtq1-0005Sg-GW; Wed, 06 Sep 2006 11:36:53 +0200
Date: Wed, 6 Sep 2006 11:36:53 +0200
From: Thomas Roessler <roessler@does-not-exist.org>
To: John Panzer <jpanzer@aol.net>
Cc: James M Snell <jasnell@gmail.com>,
        Mike Linksvayer <ml@creativecommons.org>, Ben Adida <ben@mit.edu>,
        Lisa Dusseault <lisa@osafoundation.org>,
        atom-syntax <atom-syntax@imc.org>, wendy@seltzer.org
Subject: Re: atom liense extension (was Re: [cc-tab] *important* heads up)
Message-ID: <20060906093653.GO12632@raktajino.does-not-exist.org>
Mail-Followup-To: John Panzer <jpanzer@aol.net>,
	James M Snell <jasnell@gmail.com>,
	Mike Linksvayer <ml@creativecommons.org>, Ben Adida <ben@mit.edu>,
	Lisa Dusseault <lisa@osafoundation.org>,
	atom-syntax <atom-syntax@imc.org>, wendy@seltzer.org
References: <44FD8F55.2010609@mit.edu> <1157478767.18377.47.camel@localhost.localdomain> <1157482144.18377.75.camel@localhost.localdomain> <44FDFFDE.7060304@gmail.com> <1157508255.18377.171.camel@localhost.localdomain> <44FE4599.4030707@gmail.com> <44FE5683.1030509@aol.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <44FE5683.1030509@aol.net>
User-Agent: Mutt/1.5.13 (2006-09-01)
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 79899194edc4f33a41f49410777972f8


On 2006-09-05 22:02:59 -0700, John Panzer wrote:

> Here's my rationale: Atom has explicit support in the core RFC
> 4287 syntax for 'synthetic' feeds containing entries from
> multiple sources produced by multiple authors with different
> copyrights.  RSS 2.0 doesn't have this core support.  So in the
> case of Atom, the issue is a bit more urgent.  So tackling the
> Atom case first makes sense to me.

This is an important use case for having per-item license links.  

I do not see, however, how this is a reason against having per-feed
default licenses, consistent with atom:rights.  Note, in particular,
that an aggregating party may very well be in a position to make
licensing assertions about all the entries in a feed.

-- 
Thomas Roessler   <roessler@does-not-exist.org>




From owner-atom-syntax@mail.imc.org Wed Sep 06 06:40:03 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GKup9-0006no-PP
	for atompub-archive@lists.ietf.org; Wed, 06 Sep 2006 06:40:03 -0400
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1GKup1-00074p-Ca
	for atompub-archive@lists.ietf.org; Wed, 06 Sep 2006 06:40:03 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k86ALD4B020955;
	Wed, 6 Sep 2006 03:21:13 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id k86ALDRo020954;
	Wed, 6 Sep 2006 03:21:13 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mail.gmx.net (mail.gmx.de [213.165.64.20])
	by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k86AL9dK020937
	for <atom-syntax@imc.org>; Wed, 6 Sep 2006 03:21:12 -0700 (MST)
	(envelope-from pagaltzis@gmx.de)
Received: (qmail invoked by alias); 06 Sep 2006 10:21:08 -0000
Received: from xdsl-213-196-241-95.netcologne.de (EHLO klangraum) [213.196.241.95]
  by mail.gmx.net (mp033) with SMTP; 06 Sep 2006 12:21:08 +0200
X-Authenticated: #163624
Date: Wed, 6 Sep 2006 12:21:24 +0200
From: "A. Pagaltzis" <pagaltzis@gmx.de>
To: James M Snell <jasnell@gmail.com>,
        Mike Linksvayer <ml@creativecommons.org>, Ben Adida <ben@mit.edu>,
        Lisa Dusseault <lisa@osafoundation.org>, wendy@seltzer.org,
        atom-syntax <atom-syntax@imc.org>
Subject: Re: atom license extension (Re: [cc-tab] *important* heads up)
Message-ID: <20060906102124.GB7464@klangraum>
Mail-Followup-To: James M Snell <jasnell@gmail.com>,
	Mike Linksvayer <ml@creativecommons.org>, Ben Adida <ben@mit.edu>,
	Lisa Dusseault <lisa@osafoundation.org>, wendy@seltzer.org,
	atom-syntax <atom-syntax@imc.org>
References: <44FD8F55.2010609@mit.edu> <1157478767.18377.47.camel@localhost.localdomain> <1157482144.18377.75.camel@localhost.localdomain> <20060905193613.GX12632@raktajino.does-not-exist.org> <44FDF60A.1010508@gmail.com> <20060906092847.GN12632@raktajino.does-not-exist.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20060906092847.GN12632@raktajino.does-not-exist.org>
User-Agent: Mutt/1.4.2.1i
X-Y-GMX-Trusted: 0
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id k86ALD4B020955
X-Spam-Score: 0.1 (/)
X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228


* Thomas Roessler <roessler@does-not-exist.org> [2006-09-06 11:45]:
> On 2006-09-05 15:11:22 -0700, James M Snell wrote:
> > Take, for instance, Sam Ruby's Planet feed
> > (http://planet.intertwingly.net/atom.xml).  This feed
> > consists of entries that originated from many different
> > sources, some of which may have license links, some that
> > might not.  If Sam decided to put a license link at the feed
> > level, and if license links were inherited, it would mean
> > that Sam's license would be extended over resources he may
> > have no right to license.  Obviously, that's wrong.
>=20
> Obviously, that's not obvious.  Who are we to tell that Sam
> hasn't obtained the right to attach these licenses out-of-band?

That may be a good point in this instance, but an irrelevant one.

James=E2=80=99 points out that there may be feeds where the feed
publisher has the rights to the feed as a collection, but not to
the content of individual entries. Since these cases exist, it
would be a bad idea for the licence to inherit from the feed to
entries in it.

Whether Sam in particular is or is not in that position does not
affect the principle. He=E2=80=99s not, btw: he republishes my content,
but he has no permission from me to relicense it.

Regards,
--=20
Aristotle Pagaltzis // <http://plasmasturm.org/>




From owner-atom-syntax@mail.imc.org Wed Sep 06 06:54:57 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GKv3Z-0001sr-EP
	for atompub-archive@lists.ietf.org; Wed, 06 Sep 2006 06:54:57 -0400
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1GKv3Y-0001e4-20
	for atompub-archive@lists.ietf.org; Wed, 06 Sep 2006 06:54:57 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k86AcHUs023179;
	Wed, 6 Sep 2006 03:38:17 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id k86AcHZa023178;
	Wed, 6 Sep 2006 03:38:17 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from kamino.does-not-exist.org (kamino.does-not-exist.org [217.160.221.198])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k86AcFEj023171
	for <atom-syntax@imc.org>; Wed, 6 Sep 2006 03:38:16 -0700 (MST)
	(envelope-from roessler@does-not-exist.org)
Received: from raktajino.does-not-exist.org (ip-83-99-50-11.dyn.luxdsl.pt.lu [83.99.50.11])
	(using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits))
	(No client certificate requested)
	by kamino.does-not-exist.org (Postfix) with ESMTP
	id B339C193671; Wed,  6 Sep 2006 12:38:14 +0200 (CEST)
Received: from roessler by raktajino.does-not-exist.org with local (Exim 4.62)
	(envelope-from <roessler@does-not-exist.org>)
	id 1GKunN-0005aN-Ly; Wed, 06 Sep 2006 12:38:13 +0200
Date: Wed, 6 Sep 2006 12:38:13 +0200
From: Thomas Roessler <roessler@does-not-exist.org>
To: James M Snell <jasnell@gmail.com>,
        Mike Linksvayer <ml@creativecommons.org>, Ben Adida <ben@mit.edu>,
        Lisa Dusseault <lisa@osafoundation.org>, wendy@seltzer.org,
        atom-syntax <atom-syntax@imc.org>
Subject: Re: atom license extension (Re: [cc-tab] *important* heads up)
Message-ID: <20060906103813.GS12632@raktajino.does-not-exist.org>
Mail-Followup-To: James M Snell <jasnell@gmail.com>,
	Mike Linksvayer <ml@creativecommons.org>, Ben Adida <ben@mit.edu>,
	Lisa Dusseault <lisa@osafoundation.org>, wendy@seltzer.org,
	atom-syntax <atom-syntax@imc.org>
References: <44FD8F55.2010609@mit.edu> <1157478767.18377.47.camel@localhost.localdomain> <1157482144.18377.75.camel@localhost.localdomain> <20060905193613.GX12632@raktajino.does-not-exist.org> <44FDF60A.1010508@gmail.com> <20060906092847.GN12632@raktajino.does-not-exist.org> <20060906102124.GB7464@klangraum>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20060906102124.GB7464@klangraum>
User-Agent: Mutt/1.5.13 (2006-09-01)
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k86AcGEj023173
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id k86AcHUs023179
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 97adf591118a232206bdb5a27b217034


On 2006-09-06 12:21:24 +0200, A. Pagaltzis wrote:

> James=E2=80=99 points out that there may be feeds where the feed
> publisher has the rights to the feed as a collection, but not to
> the content of individual entries. Since these cases exist, it
> would be a bad idea for the licence to inherit from the feed to
> entries in it.

The conclusion here is fallacious: These cases are a use case for
having license annotations on the feed level.  As I said elsewhere,
I'm fine with that.

However, this does not mean that the capability to set a licensing
default on the feed level is a bad thing by itself -- in particular
when that is how the other mechanism works.

We are simply talking about different use cases, and violently
agreeing that it's a bad thing to confuse these.

So, here's the proposal:

- Use <link rel=3D"license"/> for entry licenses -- either on the feed
  level, setting a default analogous to what atom:rights does, or on
  the element level.

- Introduce <link rel=3D"collection-license"/> (or whatever else you
  find suitable) for licenses about the collection, to be used only
  on the feed level.

Regards,
--=20
Thomas Roessler   <roessler@does-not-exist.org>




From owner-atom-syntax@mail.imc.org Wed Sep 06 10:17:07 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GKyDC-0001oM-Vu
	for atompub-archive@lists.ietf.org; Wed, 06 Sep 2006 10:17:06 -0400
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1GKyDB-0002Mj-Jr
	for atompub-archive@lists.ietf.org; Wed, 06 Sep 2006 10:17:06 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k86Dp8Le054142;
	Wed, 6 Sep 2006 06:51:08 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id k86Dp8Jt054139;
	Wed, 6 Sep 2006 06:51:08 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.187])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k86Dp5bF054127
	for <atom-syntax@imc.org>; Wed, 6 Sep 2006 06:51:07 -0700 (MST)
	(envelope-from jasnell@gmail.com)
Received: by nf-out-0910.google.com with SMTP id o60so214446nfa
        for <atom-syntax@imc.org>; Wed, 06 Sep 2006 06:51:04 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding;
        b=swa6ncKWqmuYQogR1AltruFxSBCqkNxMVxg9gm2Wd3Df+gk1VRklQe9xtUXD4w8GXa9wx4Kgy5o559zhUa5ycYrZ1ftZNXNKprN0KQjJM8Wip1U/BBrtSk4j8UTEpBHke22n4KzRliWbXc3dH7Y4ij02q/icA2HQ3AaS4ri2lOg=
Received: by 10.65.234.3 with SMTP id l3mr8686773qbr;
        Wed, 06 Sep 2006 06:51:04 -0700 (PDT)
Received: from ?192.168.1.104? ( [67.181.218.96])
        by mx.gmail.com with ESMTP id e19sm533058qbe.2006.09.06.06.51.02;
        Wed, 06 Sep 2006 06:51:03 -0700 (PDT)
Message-ID: <44FED244.7040008@gmail.com>
Date: Wed, 06 Sep 2006 06:51:00 -0700
From: James M Snell <jasnell@gmail.com>
User-Agent: Thunderbird 1.5.0.5 (X11/20060719)
MIME-Version: 1.0
To: John Panzer <jpanzer@aol.net>, James M Snell <jasnell@gmail.com>,
        Mike Linksvayer <ml@creativecommons.org>, Ben Adida <ben@mit.edu>,
        Lisa Dusseault <lisa@osafoundation.org>,
        atom-syntax <atom-syntax@imc.org>, wendy@seltzer.org
Subject: Re: atom liense extension (was Re: [cc-tab] *important* heads up)
References: <44FD8F55.2010609@mit.edu> <1157478767.18377.47.camel@localhost.localdomain> <1157482144.18377.75.camel@localhost.localdomain> <44FDFFDE.7060304@gmail.com> <1157508255.18377.171.camel@localhost.localdomain> <44FE4599.4030707@gmail.com> <44FE5683.1030509@aol.net> <20060906093653.GO12632@raktajino.does-not-exist.org>
In-Reply-To: <20060906093653.GO12632@raktajino.does-not-exist.org>
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>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3


The problem with specifying a per-feed default license is that there is
currently no way of explicitly indicating that an entry does not have a
license or that any particular entry should not inherit the default
feed-level license.

- james

Thomas Roessler wrote:
> On 2006-09-05 22:02:59 -0700, John Panzer wrote:
> 
>> Here's my rationale: Atom has explicit support in the core RFC
>> 4287 syntax for 'synthetic' feeds containing entries from
>> multiple sources produced by multiple authors with different
>> copyrights.  RSS 2.0 doesn't have this core support.  So in the
>> case of Atom, the issue is a bit more urgent.  So tackling the
>> Atom case first makes sense to me.
> 
> This is an important use case for having per-item license links.  
> 
> I do not see, however, how this is a reason against having per-feed
> default licenses, consistent with atom:rights.  Note, in particular,
> that an aggregating party may very well be in a position to make
> licensing assertions about all the entries in a feed.
> 




From owner-atom-syntax@mail.imc.org Wed Sep 06 11:02:23 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GKyv0-0006A3-Sg
	for atompub-archive@lists.ietf.org; Wed, 06 Sep 2006 11:02:23 -0400
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1GKyux-0001WW-Gg
	for atompub-archive@lists.ietf.org; Wed, 06 Sep 2006 11:02:22 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k86Ei2eL059302;
	Wed, 6 Sep 2006 07:44:02 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id k86Ei2xV059301;
	Wed, 6 Sep 2006 07:44:02 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from kamino.does-not-exist.org (kamino.does-not-exist.org [217.160.221.198])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k86Ei0SI059282
	for <atom-syntax@imc.org>; Wed, 6 Sep 2006 07:44:01 -0700 (MST)
	(envelope-from roessler@does-not-exist.org)
Received: from raktajino.does-not-exist.org (ip-83-99-50-11.dyn.luxdsl.pt.lu [83.99.50.11])
	(using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits))
	(No client certificate requested)
	by kamino.does-not-exist.org (Postfix) with ESMTP
	id 7061E19373C; Wed,  6 Sep 2006 16:43:59 +0200 (CEST)
Received: from roessler by raktajino.does-not-exist.org with local (Exim 4.62)
	(envelope-from <roessler@does-not-exist.org>)
	id 1GKydC-0005uy-BF; Wed, 06 Sep 2006 16:43:58 +0200
Date: Wed, 6 Sep 2006 16:43:58 +0200
From: Thomas Roessler <roessler@does-not-exist.org>
To: James M Snell <jasnell@gmail.com>
Cc: John Panzer <jpanzer@aol.net>, Mike Linksvayer <ml@creativecommons.org>,
        Ben Adida <ben@mit.edu>, Lisa Dusseault <lisa@osafoundation.org>,
        atom-syntax <atom-syntax@imc.org>, wendy@seltzer.org
Subject: Re: atom license extension (was Re: [cc-tab] *important* heads up)
Message-ID: <20060906144358.GI12632@raktajino.does-not-exist.org>
Mail-Followup-To: James M Snell <jasnell@gmail.com>,
	John Panzer <jpanzer@aol.net>,
	Mike Linksvayer <ml@creativecommons.org>, Ben Adida <ben@mit.edu>,
	Lisa Dusseault <lisa@osafoundation.org>,
	atom-syntax <atom-syntax@imc.org>, wendy@seltzer.org
References: <44FD8F55.2010609@mit.edu> <1157478767.18377.47.camel@localhost.localdomain> <1157482144.18377.75.camel@localhost.localdomain> <44FDFFDE.7060304@gmail.com> <1157508255.18377.171.camel@localhost.localdomain> <44FE4599.4030707@gmail.com> <44FE5683.1030509@aol.net> <20060906093653.GO12632@raktajino.does-not-exist.org> <44FED244.7040008@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <44FED244.7040008@gmail.com>
User-Agent: Mutt/1.5.13 (2006-09-01)
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64


That means that, in some use cases, setting a default is the wrong
thing to do.  That's the same limitation you have for atom:rights.
It's a limitation that can be stated in the specification.  But I
don't see how it is a limitation that means there must not be a
default license feature available to those who decide to use it.
-- 
Thomas Roessler   <roessler@does-not-exist.org>






On 2006-09-06 06:51:00 -0700, James M Snell wrote:
> From: James M Snell <jasnell@gmail.com>
> To: John Panzer <jpanzer@aol.net>, James M Snell <jasnell@gmail.com>,
> 	Mike Linksvayer <ml@creativecommons.org>, Ben Adida <ben@mit.edu>,
> 	Lisa Dusseault <lisa@osafoundation.org>,
> 	atom-syntax <atom-syntax@imc.org>, wendy@seltzer.org
> Date: Wed, 06 Sep 2006 06:51:00 -0700
> Subject: Re: atom liense extension (was Re: [cc-tab] *important* heads
> 	up)
> List-ID: <atom-syntax.imc.org>
> X-Spam-Level: 
> 
> 
> The problem with specifying a per-feed default license is that there is
> currently no way of explicitly indicating that an entry does not have a
> license or that any particular entry should not inherit the default
> feed-level license.
> 
> - james
> 
> Thomas Roessler wrote:
> > On 2006-09-05 22:02:59 -0700, John Panzer wrote:
> > 
> >> Here's my rationale: Atom has explicit support in the core RFC
> >> 4287 syntax for 'synthetic' feeds containing entries from
> >> multiple sources produced by multiple authors with different
> >> copyrights.  RSS 2.0 doesn't have this core support.  So in the
> >> case of Atom, the issue is a bit more urgent.  So tackling the
> >> Atom case first makes sense to me.
> > 
> > This is an important use case for having per-item license links.  
> > 
> > I do not see, however, how this is a reason against having per-feed
> > default licenses, consistent with atom:rights.  Note, in particular,
> > that an aggregating party may very well be in a position to make
> > licensing assertions about all the entries in a feed.
> > 
> 
> 




From owner-atom-syntax@mail.imc.org Wed Sep 06 13:02:06 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GL0ms-0002V4-T4
	for atompub-archive@lists.ietf.org; Wed, 06 Sep 2006 13:02:06 -0400
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1GL0mr-0003dv-Ff
	for atompub-archive@lists.ietf.org; Wed, 06 Sep 2006 13:02:06 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k86GUxta069636;
	Wed, 6 Sep 2006 09:30:59 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id k86GUxoY069635;
	Wed, 6 Sep 2006 09:30:59 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mcom.com (c3po.aoltw.net [64.236.137.25])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k86GUraZ069624
	for <atom-syntax@imc.org>; Wed, 6 Sep 2006 09:30:58 -0700 (MST)
	(envelope-from jpanzer@aol.net)
Received: from JOHNPANZER.ad.aol.aoltw.net (h-10-169-155-222.nscp.aoltw.net [10.169.155.222])
	by mcom.com (8.10.0/8.10.0) with ESMTP id k86GT6W24965;
	Wed, 6 Sep 2006 09:29:11 -0700 (PDT)
Date: Wed, 6 Sep 2006 09:29:06 -0700
From: "John Panzer" <jpanzer@aol.net>
Subject: Re: atom license extension (Re: [cc-tab] *important* heads up)
To: "Bob Wyman" <bob@wyman.us>
cc: "'Wendy Seltzer'" <wendy@seltzer.org>,
        "'James M Snell'" <jasnell@gmail.com>,
        "'Thomas Roessler'" <tlr@w3.org>,
        "'Mike Linksvayer'" <ml@creativecommons.org>,
        "'Ben Adida'" <ben@mit.edu>,
        "'Lisa Dusseault'" <lisa@osafoundation.org>,
        "'atom-syntax'" <atom-syntax@imc.org>
Message-ID: <44FEF751.5080203@aol.net>
X-Mailer: AOL Communicator (20030919.3 Win)
Organization: AOL
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>
X-Spam-Score: 2.6 (++)
X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a


<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <title></title>
</head>
<body bgcolor="#ffffff">
<font face="Arial,sans-serif"><font size="2">Bob Wyman wrote:
</font></font>
<blockquote cite="mid006f01c6d17d$4a91bca0$6400a8c0@BOBSLAPTOP"
 type="cite"><font face="Arial,sans-serif" size="2"></font><font
 size="2"><font face="Arial,sans-serif">...</font></font>
  <pre wrap="">The most<br>interesting cases will be those licenses that attempt to assert limitations<br>to rights which would normally be considered to be granted to consumers of<br>feeds. Such rights would include things like "Fair Use" and "implied<br>licenses." It is *vitally* important to our community that we ensure that<br>such restrictive licenses are not encouraged or facilitated by this rfc.<br>  </pre>
  <font face="Arial,sans-serif" size="2"></font></blockquote>
<font face="Arial,sans-serif"><font size="2">This is a critical point.&nbsp;
Without this, implementors cannot safely
ignore licenses they don't understand (falling back to things like
"fair use" if they can't find any licenses that grant additional
copying rights).&nbsp; This means that implementors would likely have to
drop feeds containing new licenses on the floor, meaning that new
license schemes would never be deployed.<br>
</font></font>
<blockquote cite="mid006f01c6d17d$4a91bca0$6400a8c0@BOBSLAPTOP"
 type="cite"><font face="Arial,sans-serif" size="2"> </font>
  <pre wrap="">...<br>    Thus, it would seem that the only effective use of the license link<br>is to grant rights not to restrict them.</pre>
</blockquote>
<font size="2"><font face="Arial,sans-serif">Yes.&nbsp; Given the current
murky and complicated legal situation with implied licenses, fair use,
etc., granting explicit and well defined rights is a huge win for
everyone.<br>
<br>
</font></font>
<blockquote cite="mid006f01c6d17d$4a91bca0$6400a8c0@BOBSLAPTOP"
 type="cite">
  <pre wrap=""><br>The second sentence in 1.1 is:<br>  </pre>
  <font face="Arial,sans-serif" size="2"> </font>
  <blockquote type="cite"><font face="Arial,sans-serif" size="2"> </font>
    <blockquote type="cite"><font face="Arial,sans-serif" size="2"> </font>
      <pre wrap="">Nor can a license associated with a feed or entry<br>restrict or forbid access to, redistribution, aggregation,<br>caching and display of those items by third party<br>intermediaries such as search engines and so-called<br>"online aggregators".<br>      </pre>
      <font face="Arial,sans-serif" size="2"> </font></blockquote>
    <font face="Arial,sans-serif" size="2"> </font></blockquote>
  <font face="Arial,sans-serif" size="2"> </font>
  <pre wrap=""><!---->    This second part of 1.1 is stating support for the theory that the<br>act of publishing data in the Atom format creates an "implied license" for<br>the limited purpose of syndication and lists a number of processes which are<br>considered to be part of the syndication process. Hopefully, my discussion<br>of the first sentence explains what this is all about.<br>    My only suggestion for this sentence is that it might be less<br>strongly worded. Given that the law in this area is not settled, it might<br>make sense not to say "Nor can a license... restrict..." Rather, it might be<br>more accurate to say something like: "It is believed that a license ...<br>cannot restrict...."<br></pre>
</blockquote>
<font size="2"><font face="Arial,sans-serif">How about (IANAL of
course):<br>
<br>
</font></font><font size="2"><font face="Arial,sans-serif">"Nor can a
license.... restrict or remove any implied copy or usage rights which
would otherwise exist in the absence of the license."<br>
<br>
The intent being that adding a license, or a new type of license, is
always safe:&nbsp; If what you're doing with content is allowable, if the
feed provider adds a license, it is still allowable.&nbsp; <br>
<br>
-John Panzer<br>
<br>
</font></font><font face="Arial,sans-serif"><font size="2"></font></font>
</body>
</html>




From owner-atom-syntax@mail.imc.org Wed Sep 06 13:08:58 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GL0tW-0004gE-Pz
	for atompub-archive@lists.ietf.org; Wed, 06 Sep 2006 13:08:58 -0400
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1GL0tV-0004pX-Dp
	for atompub-archive@lists.ietf.org; Wed, 06 Sep 2006 13:08:58 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k86Gm6AN070718;
	Wed, 6 Sep 2006 09:48:06 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id k86Gm6BW070717;
	Wed, 6 Sep 2006 09:48:06 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from omr4.networksolutionsemail.com (omr4.networksolutionsemail.com [205.178.146.54])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k86Gm28o070707
	for <atom-syntax@imc.org>; Wed, 6 Sep 2006 09:48:04 -0700 (MST)
	(envelope-from bob@wyman.us)
Received: from mail.networksolutionsemail.com (ns-omr4.mgt.netsol.com [10.49.6.67])
	by omr4.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id k86GlPbZ029662
	for <atom-syntax@imc.org>; Wed, 6 Sep 2006 12:47:31 -0400
Received: (qmail 20875 invoked by uid 78); 6 Sep 2006 16:47:25 -0000
Received: from unknown (HELO BOBSLAPTOP) (69.201.178.152)
  by ns-omr4.lb.hosting.dc2.netsol.com with SMTP; 6 Sep 2006 16:47:25 -0000
From: "Bob Wyman" <bob@wyman.us>
To: "'Thomas Roessler'" <roessler@does-not-exist.org>,
        "'Bob Wyman'" <bob@wyman.us>
Cc: "'Wendy Seltzer'" <wendy@seltzer.org>,
        "'James M Snell'" <jasnell@gmail.com>,
        "'Mike Linksvayer'" <ml@creativecommons.org>,
        "'Ben Adida'" <ben@mit.edu>,
        "'Lisa Dusseault'" <lisa@osafoundation.org>,
        "'atom-syntax'" <atom-syntax@imc.org>
Subject: RE: atom license extension (Re: [cc-tab] *important* heads up)
Date: Wed, 6 Sep 2006 12:47:09 -0400
Message-ID: <00b601c6d1d4$1c0995e0$6400a8c0@BOBSLAPTOP>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962
Thread-Index: AcbRkyzhp9UsE/fPTzmDRkwDVVrM4wAP2fMA
In-Reply-To: <20060906090212.GM12632@raktajino.does-not-exist.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>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a


Thomas Roessler wrote:
> It's fine to point out the lack of an enforceable binding on a
> technical level, but I don't think this spec is the place to
> discuss the legal implications that this might have.
	If the spec does not make statements concerning the intended legal
implications of a feature which clearly addresses legal issues, the result
will almost inevitably be wide-spread misunderstanding of the implications
of using the feature. The mere act of going to the trouble of specifying the
license link indicates that the authors expect that there will be some
implication of having used the feature. The question that many readers will
have is: "What are the intended implications?" Leaving the answer to guess
work is not useful, I think.
	Given the unsettled and potentially dynamic state of the law in this
area, I certainly agree that the spec should not make pronouncements
concerning what the law is in this case. But I don't see any valid argument
against making statements of intent that may, or may not, be in conflict
with the law as it is or may one day be.
	The authors of the specification have, I think, not only good reason
to state their intention but an obligation to do so. Warning implementers
that the use of the license link may not, in at least some situations and in
some legal systems, create a legally enforceable binding is the right thing
to do.

	bob wyman





From owner-atom-syntax@mail.imc.org Wed Sep 06 13:19:01 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GL13F-0007Xh-S9
	for atompub-archive@lists.ietf.org; Wed, 06 Sep 2006 13:19:01 -0400
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1GL13E-0006XV-Gk
	for atompub-archive@lists.ietf.org; Wed, 06 Sep 2006 13:19:01 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k86GsVXp071515;
	Wed, 6 Sep 2006 09:54:31 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id k86GsVKS071513;
	Wed, 6 Sep 2006 09:54:31 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from kamino.does-not-exist.org (kamino.does-not-exist.org [217.160.221.198])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k86GsRgu071503
	for <atom-syntax@imc.org>; Wed, 6 Sep 2006 09:54:30 -0700 (MST)
	(envelope-from roessler@does-not-exist.org)
Received: from raktajino.does-not-exist.org (ip-83-99-50-11.dyn.luxdsl.pt.lu [83.99.50.11])
	(using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits))
	(No client certificate requested)
	by kamino.does-not-exist.org (Postfix) with ESMTP
	id 8E4EB193694; Wed,  6 Sep 2006 18:54:26 +0200 (CEST)
Received: from roessler by raktajino.does-not-exist.org with local (Exim 4.62)
	(envelope-from <roessler@does-not-exist.org>)
	id 1GL0fR-0006AE-Gz; Wed, 06 Sep 2006 18:54:25 +0200
Date: Wed, 6 Sep 2006 18:54:25 +0200
From: Thomas Roessler <roessler@does-not-exist.org>
To: Bob Wyman <bob@wyman.us>
Cc: "'Wendy Seltzer'" <wendy@seltzer.org>,
        "'James M Snell'" <jasnell@gmail.com>,
        "'Mike Linksvayer'" <ml@creativecommons.org>,
        "'Ben Adida'" <ben@mit.edu>,
        "'Lisa Dusseault'" <lisa@osafoundation.org>,
        "'atom-syntax'" <atom-syntax@imc.org>
Subject: Re: atom license extension (Re: [cc-tab] *important* heads up)
Message-ID: <20060906165425.GV12632@raktajino.does-not-exist.org>
Mail-Followup-To: Bob Wyman <bob@wyman.us>,
	'Wendy Seltzer' <wendy@seltzer.org>,
	'James M Snell' <jasnell@gmail.com>,
	'Mike Linksvayer' <ml@creativecommons.org>,
	'Ben Adida' <ben@mit.edu>, 'Lisa Dusseault' <lisa@osafoundation.org>,
	'atom-syntax' <atom-syntax@imc.org>
References: <20060906090212.GM12632@raktajino.does-not-exist.org> <00b601c6d1d4$1c0995e0$6400a8c0@BOBSLAPTOP>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <00b601c6d1d4$1c0995e0$6400a8c0@BOBSLAPTOP>
User-Agent: Mutt/1.5.13 (2006-09-01)
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 79899194edc4f33a41f49410777972f8


On 2006-09-06 12:47:09 -0400, Bob Wyman wrote:

> 	The authors of the specification have, I think, not only
> good reason to state their intention but an obligation to do so.
> Warning implementers that the use of the license link may not, in
> at least some situations and in some legal systems, create a
> legally enforceable binding is the right thing to do.

The intent of this spec is to give those who publish a feed a way to
assert what licensing conditions apply to certain parts of that
feed.

That's what the spec should say; anything else -- in particular
elaborate discussions of corner cases -- is going to cause
confusion.

-- 
Thomas Roessler   <roessler@does-not-exist.org>




From owner-atom-syntax@mail.imc.org Wed Sep 06 14:04:21 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GL1l7-0007R8-TF
	for atompub-archive@lists.ietf.org; Wed, 06 Sep 2006 14:04:21 -0400
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1GL1l6-0008MM-GB
	for atompub-archive@lists.ietf.org; Wed, 06 Sep 2006 14:04:21 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k86HlNrR075515;
	Wed, 6 Sep 2006 10:47:23 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id k86HlNss075514;
	Wed, 6 Sep 2006 10:47:23 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from omr3.networksolutionsemail.com (omr3.networksolutionsemail.com [205.178.146.53])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k86HlMf9075508
	for <atom-syntax@imc.org>; Wed, 6 Sep 2006 10:47:22 -0700 (MST)
	(envelope-from bob@wyman.us)
Received: from mail.networksolutionsemail.com (ns-omr3.mgt.netsolmail.com [10.49.6.66])
	by omr3.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id k86Hl5i7020985
	for <atom-syntax@imc.org>; Wed, 6 Sep 2006 13:47:08 -0400
Received: (qmail 19280 invoked by uid 78); 6 Sep 2006 17:47:05 -0000
Received: from unknown (HELO BOBSLAPTOP) (69.201.178.152)
  by ns-omr3.lb.hosting.dc2.netsol.com with SMTP; 6 Sep 2006 17:47:05 -0000
From: "Bob Wyman" <bob@wyman.us>
To: "'Thomas Roessler'" <roessler@does-not-exist.org>,
        "'Bob Wyman'" <bob@wyman.us>
Cc: "'Wendy Seltzer'" <wendy@seltzer.org>,
        "'James M Snell'" <jasnell@gmail.com>,
        "'Mike Linksvayer'" <ml@creativecommons.org>,
        "'Ben Adida'" <ben@mit.edu>,
        "'Lisa Dusseault'" <lisa@osafoundation.org>,
        "'atom-syntax'" <atom-syntax@imc.org>
Subject: RE: atom license extension (Re: [cc-tab] *important* heads up)
Date: Wed, 6 Sep 2006 13:46:54 -0400
Message-ID: <00d301c6d1dc$716ac1f0$6400a8c0@BOBSLAPTOP>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962
Thread-Index: AcbR1R2CJshv21inQXKW7HpY2WixpgAAwIYQ
In-Reply-To: <20060906165425.GV12632@raktajino.does-not-exist.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>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b


Thomas Roessler wrote:
> The intent of this spec is to give those who publish a
> feed a way to assert what licensing conditions apply to
> certain parts of that feed.
	If a mechanism is provided for "asserting" rights, without warning
folk that the assertions may not be effective, the assumption on the part of
many folk will be that the assertion is, in fact, effective. The result will
be confusion and that confusion can be costly. (Note: I also don't think it
is responsible to sell guns without safety warnings...)
	In this case, protection of the limited implied license to syndicate
is a matter of extreme importance to the syndication network. Those of us
who run or have run syndication services already have enough trouble with
folk who stick random "rights language" in their feeds and then think that
these assertions are somehow effective -- or even that the automated
processes that we run can recognize that the language is present. The number
of folk who have attempted, usually unintentionally, to "poison the stream"
of syndication is large.
	One excellent example of the confusion that exists is that many
people actually think that Creative Commons licenses are restrictive! While
the CC licenses are generally well drafted, very few people actually read
the things. As a result, there are numerous folk who honestly believe that
Creative Commons licenses can be used as a form of DRM to restrict use. They
believe, for instance, that a CC non-commercial use license actually
restricts commercial use when, in fact, such a license is explicitly silent
on the subject and simply leaves in place pre-existing restrictions (such as
copyright), if there are any, on commercial use.
	In this context, I'm particularly concerned about people who will
try to use license assertions to override or diminish the vital but limited
implied license to syndicate -- for instance, when the syndication is
performed by "commercial" organizations. We already have many folk who think
that a CC Non-Commercial license has this effect when attached to a feed or
entry. I think it is in our interest to do what we can to avoid further
confusion by warning people of the limits of their assertions in the
specification. There will still be many who don't read the spec; however,
we'll be providing support to those who try to explain it...

	bob wyman





From owner-atom-syntax@mail.imc.org Wed Sep 06 14:46:52 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GL2QG-00008V-I8
	for atompub-archive@lists.ietf.org; Wed, 06 Sep 2006 14:46:52 -0400
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1GL2QC-0001qV-30
	for atompub-archive@lists.ietf.org; Wed, 06 Sep 2006 14:46:52 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k86IPR3j080114;
	Wed, 6 Sep 2006 11:25:27 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id k86IPR85080113;
	Wed, 6 Sep 2006 11:25:27 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mail5.sea5.speakeasy.net (mail5.sea5.speakeasy.net [69.17.117.7])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k86IPOkq080104
	for <atom-syntax@imc.org>; Wed, 6 Sep 2006 11:25:26 -0700 (MST)
	(envelope-from wendy@seltzer.com)
Received: (qmail 4539 invoked from network); 6 Sep 2006 18:25:18 -0000
Received: from ghost.bibliotrack.com (HELO figaro.seltzer.com) (wseltzer@[216.254.98.187])
          (envelope-sender <wendy@seltzer.com>)
          by mail5.sea5.speakeasy.net (qmail-ldap-1.03) with AES256-SHA encrypted SMTP
          for <bob@wyman.us>; 6 Sep 2006 18:25:18 -0000
Message-Id: <7.0.0.10.2.20060906135801.05b1d0e8@seltzer.com>
X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.10 (Beta)
Date: Wed, 06 Sep 2006 14:23:10 -0400
To: "Bob Wyman" <bob@wyman.us>, "John Panzer" <jpanzer@aol.net>
From: Wendy Seltzer <wendy@seltzer.org>
Subject: Re: atom license extension (Re: [cc-tab] *important* heads up)
Cc: "'Wendy Seltzer'" <wendy@seltzer.org>,
        "'James M Snell'" <jasnell@gmail.com>,
        "'Thomas Roessler'" <tlr@w3.org>,
        "'Mike Linksvayer'" <ml@creativecommons.org>,
        "'Ben Adida'" <ben@mit.edu>,
        "'Lisa Dusseault'" <lisa@osafoundation.org>,
        "'atom-syntax'" <atom-syntax@imc.org>
In-Reply-To: <44FEF751.5080203@aol.net>
References: <44FEF751.5080203@aol.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>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 386e0819b1192672467565a524848168


At 12:29 PM 9/6/2006, John Panzer wrote:
>Bob Wyman wrote:
>>...
>>The most
>>interesting cases will be those licenses that attempt to assert limitations
>>to rights which would normally be considered to be granted to consumers of
>>feeds. Such rights would include things like "Fair Use" and "implied
>>licenses." It is *vitally* important to our community that we ensure that
>>such restrictive licenses are not encouraged or facilitated by this rfc.

Restrictions on fair use couldn't be imposed unilaterally by license, 
but only by a contract (fictionally accepted by click-wrap, or 
actually negotiated and accepted).

The concern about limiting implied licenses is important, though.  By 
definition, an implied license is one that's presumed from the 
context of an offering and by the absence of a contrary explicit 
license.  If as a factual matter, many people have been acting based 
on implied licenses of broader scope than either fair use or what 
would be chosen in an explicitly linked license, then you might say 
it's better not to provide this encouragement to link licenses at all 
(and hoping that time and general practice will morph those implied 
terms into fair uses).

If the rfc encourages people to add licenses, it opens up the 
possibility that their explicit terms will contradict and override 
what has previously been implied.

>>
>This is a critical point.  Without this, implementors cannot safely 
>ignore licenses they don't understand (falling back to things like 
>"fair use" if they can't find any licenses that grant additional 
>copying rights).  This means that implementors would likely have to 
>drop feeds containing new licenses on the floor, meaning that new 
>license schemes would never be deployed.
>>
>>...
>>     Thus, it would seem that the only effective use of the license link
>>is to grant rights not to restrict them.
>Yes.  Given the current murky and complicated legal situation with 
>implied licenses, fair use, etc., granting explicit and well defined 
>rights is a huge win for everyone.

I don't think there's a legal mechanism for telling people "you may 
only use this format if you grant a license equally or more 
permissive than X."  (at least none short of patent claims on the 
format itself...)

--Wendy




>>The second sentence in 1.1 is:
>>
>>>>
>>>>Nor can a license associated with a feed or entry
>>>>restrict or forbid access to, redistribution, aggregation,
>>>>caching and display of those items by third party
>>>>intermediaries such as search engines and so-called
>>>>"online aggregators".
>>>>
>>
>>     This second part of 1.1 is stating support for the theory that the
>>act of publishing data in the Atom format creates an "implied license" for
>>the limited purpose of syndication and lists a number of processes which are
>>considered to be part of the syndication process. Hopefully, my discussion
>>of the first sentence explains what this is all about.
>>     My only suggestion for this sentence is that it might be less
>>strongly worded. Given that the law in this area is not settled, it might
>>make sense not to say "Nor can a license... restrict..." Rather, it might be
>>more accurate to say something like: "It is believed that a license ...
>>cannot restrict...."
>How about (IANAL of course):
>
>"Nor can a license.... restrict or remove any implied copy or usage 
>rights which would otherwise exist in the absence of the license."
>
>The intent being that adding a license, or a new type of license, is 
>always safe:  If what you're doing with content is allowable, if the 
>feed provider adds a license, it is still allowable.
>
>-John Panzer

--
Wendy Seltzer -- wendy@seltzer.org
Visiting Assistant Professor of Law, Brooklyn Law School
Fellow, Berkman Center for Internet & Society
http://cyber.law.harvard.edu/seltzer.html
http://www.chillingeffects.org/  




From owner-atom-syntax@mail.imc.org Wed Sep 06 16:27:16 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GL3zP-0006xC-WF
	for atompub-archive@lists.ietf.org; Wed, 06 Sep 2006 16:27:16 -0400
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1GL3zL-0006hH-Ia
	for atompub-archive@lists.ietf.org; Wed, 06 Sep 2006 16:27:15 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k86K4aM3089776;
	Wed, 6 Sep 2006 13:04:36 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id k86K4a14089775;
	Wed, 6 Sep 2006 13:04:36 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from omr9.networksolutionsemail.com (omr9.networksolutionsemail.com [205.178.146.59])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k86K4XUw089757
	for <atom-syntax@imc.org>; Wed, 6 Sep 2006 13:04:36 -0700 (MST)
	(envelope-from bob@wyman.us)
Received: from mail.networksolutionsemail.com (ns-omr9.mgt.hosting.dc2.netsol.com [10.49.6.72])
	by omr9.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id k86K4MNX030837
	for <atom-syntax@imc.org>; Wed, 6 Sep 2006 16:04:27 -0400
Received: (qmail 7649 invoked by uid 78); 6 Sep 2006 20:04:22 -0000
Received: from unknown (HELO BOBSLAPTOP) (69.201.178.152)
  by ns-omr9.lb.hosting.dc2.netsol.com with SMTP; 6 Sep 2006 20:04:22 -0000
From: "Bob Wyman" <bob@wyman.us>
To: "'Wendy Seltzer'" <wendy@seltzer.org>, "'Bob Wyman'" <bob@wyman.us>,
        "'John Panzer'" <jpanzer@aol.net>
Cc: "'James M Snell'" <jasnell@gmail.com>, "'Thomas Roessler'" <tlr@w3.org>,
        "'Mike Linksvayer'" <ml@creativecommons.org>,
        "'Ben Adida'" <ben@mit.edu>,
        "'Lisa Dusseault'" <lisa@osafoundation.org>,
        "'atom-syntax'" <atom-syntax@imc.org>
Subject: RE: atom license extension (Re: [cc-tab] *important* heads up)
Date: Wed, 6 Sep 2006 16:04:08 -0400
Message-ID: <001601c6d1ef$9ef6ef50$6400a8c0@BOBSLAPTOP>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962
Thread-index: AcbR4c/AaH5jUva5RNmaVtsGEetAOgADBK/g
In-Reply-To: <7.0.0.10.2.20060906135801.05b1d0e8@seltzer.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>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2


Wendy Seltzer wrote:
> The concern about limiting implied licenses is important...
> If the rfc encourages people to add licenses, it opens up
> the possibility that their explicit terms will contradict
> and override what has previously been implied.
	This is precisely why I have normally argued against adding rights
and licenses mechanism to Atom and other formats. Unfortunately, it is has
been a losing battle (Atom has <rights/>) so, I'm now trying the tack of
attempting to get explanatory text and weakness in the language in order to
mitigate some of the damage that might be caused.
	Oddly, I think part of the push for these dangerous licensing
mechanisms is the result of success of Creative Commons. We may be seeing
that a movement intended to expand rights will indirectly create a situation
where rights are more easily restricted. People really like the CC mechanism
for granting rights and as a result want cleaner and better understood means
for associating Creative Commons licenses with their content. Unfortunately,
an unintended consequence of satisfying this desire to publish CC licenses
might be that it becomes easier and more common for folk to publish
restrictive licenses.
	Readers of this thread might be interested to see that Denise Howell
has been discussing very similar issues on her new Logarithms blog.[1][2]
I've put some comments in there and have also responded in length concerning
what I, as a non-lawyer, consider some of the implied licenses that attach
to RSS/Atom syndicated content.[3]

	bob wyman

[1] http://blogs.zdnet.com/Howell/?p=17
[2] http://blogs.zdnet.com/Howell/?p=18
[3] http://www.wyman.us/main/2006/09/magazine_or_mus.html





From owner-atom-syntax@mail.imc.org Wed Sep 06 18:32:48 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GL5wu-00080T-2B
	for atompub-archive@lists.ietf.org; Wed, 06 Sep 2006 18:32:48 -0400
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1GL5ws-0001LU-LD
	for atompub-archive@lists.ietf.org; Wed, 06 Sep 2006 18:32:48 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k86M8FrO001186;
	Wed, 6 Sep 2006 15:08:15 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id k86M8FV9001185;
	Wed, 6 Sep 2006 15:08:15 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from sccrmhc11.comcast.net (sccrmhc11.comcast.net [63.240.77.81])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k86M8EUO001178
	for <atom-syntax@imc.org>; Wed, 6 Sep 2006 15:08:14 -0700 (MST)
	(envelope-from antone@geckotribe.com)
Received: from [192.168.0.3] (c-67-182-206-93.hsd1.ut.comcast.net[67.182.206.93])
          by comcast.net (sccrmhc11) with SMTP
          id <2006090622080801100ca4j8e>; Wed, 6 Sep 2006 22:08:08 +0000
Mime-Version: 1.0 (Apple Message framework v752.2)
In-Reply-To: <20060906103813.GS12632@raktajino.does-not-exist.org>
References: <44FD8F55.2010609@mit.edu> <1157478767.18377.47.camel@localhost.localdomain> <1157482144.18377.75.camel@localhost.localdomain> <20060905193613.GX12632@raktajino.does-not-exist.org> <44FDF60A.1010508@gmail.com> <20060906092847.GN12632@raktajino.does-not-exist.org> <20060906102124.GB7464@klangraum> <20060906103813.GS12632@raktajino.does-not-exist.org>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <A3D79EAB-904C-4A16-95FB-19D677919B8F@geckotribe.com>
Content-Transfer-Encoding: 7bit
From: Antone Roundy <antone@geckotribe.com>
Subject: Re: atom license extension (Re: [cc-tab] *important* heads up)
Date: Wed, 6 Sep 2006 16:08:06 -0600
To: atom-syntax@imc.org
X-Mailer: Apple Mail (2.752.2)
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793


On Sep 6, 2006, at 7:51 AM, James M Snell wrote:
> The problem with specifying a per-feed default license is that  
> there is
> currently no way of explicitly indicating that an entry does not  
> have a
> license or that any particular entry should not inherit the default
> feed-level license.

With respect to atom:rights (from RFC 4287 section 4.2.10):

    If an atom:entry element does not contain an atom:rights element,
    then the atom:rights element of the containing atom:feed element, if
    present, is considered to apply to the entry.

Thus, at the entry level, <atom:rights /> would (certainly ought to!)  
detach a feed level atom:rights element from the entry without  
replacing it with anything.  With <link rel="license"..., I'm not  
sure how you'd do the same thing.  Is it possible to specify a null  
URI?  <link rel="license" href="" /> points to the in-scope xml:base  
URI, right?  Perhaps the specification could define a "null license"  
URI.

With respect to the issue of aggregate feeds, I had thought that the  
existence of an atom:source element at the entry level blocked any  
"inheritance" of the feed metadata, but looking at RFC 4287, I don't  
see that explicitly stated.  Certainly if atom:source contains  
atom:rights, then that element overrides the feed-level atom:rights  
of the aggregate feed, but if neither atom:source nor atom:entry  
contains an atom:rights element, what then?  Perhaps in that case,  
the aggregator should add <atom:rights /> as a child of atom:source  
(I'd think that preferable to adding it as a child of atom:entry).

On Sep 6, 2006, at 4:38 AM, Thomas Roessler wrote:
> So, here's the proposal:
>
> - Use <link rel="license"/> for entry licenses -- either on the feed
>   level, setting a default analogous to what atom:rights does, or on
>   the element level.
>
> - Introduce <link rel="collection-license"/> (or whatever else you
>   find suitable) for licenses about the collection, to be used only
>   on the feed level.

If there's a @rel="license" at the feed level, but no rel="collection- 
license", does the @rel="license" also become a "collection- 
license"?  (People who don't read the spec would probably think so).   
If there is no license for the collection, but one wishes to specify  
a default license for the entries, a "null license" would once again  
be useful.

Antone




From owner-atom-syntax@mail.imc.org Wed Sep 06 19:20:51 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GL6hO-000763-TV
	for atompub-archive@lists.ietf.org; Wed, 06 Sep 2006 19:20:50 -0400
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1GL6hN-00025D-HK
	for atompub-archive@lists.ietf.org; Wed, 06 Sep 2006 19:20:50 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k86N5Xfk008073;
	Wed, 6 Sep 2006 16:05:33 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id k86N5XaJ008071;
	Wed, 6 Sep 2006 16:05:33 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from omr8.networksolutionsemail.com (omr8.networksolutionsemail.com [205.178.146.58])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k86N5SMc008061
	for <atom-syntax@imc.org>; Wed, 6 Sep 2006 16:05:32 -0700 (MST)
	(envelope-from bob@wyman.us)
Received: from mail.networksolutionsemail.com (ns-omr8.mgt.netsol.com [10.49.6.71])
	by omr8.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id k86N5RqE012962
	for <atom-syntax@imc.org>; Wed, 6 Sep 2006 19:05:27 -0400
Received: (qmail 15112 invoked by uid 78); 6 Sep 2006 23:05:27 -0000
Received: from unknown (HELO BOBSLAPTOP) (69.201.178.152)
  by ns-omr8.lb.hosting.dc2.netsol.com with SMTP; 6 Sep 2006 23:05:27 -0000
From: "Bob Wyman" <bob@wyman.us>
To: "'Antone Roundy'" <antone@geckotribe.com>, <atom-syntax@imc.org>
Subject: RE: atom license extension (Re: [cc-tab] *important* heads up)
Date: Wed, 6 Sep 2006 19:05:16 -0400
Message-ID: <007601c6d208$eaa103f0$6400a8c0@BOBSLAPTOP>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962
Thread-index: AcbSBeJMC2sZ6wltRKG3uD1C+zf03QAAD9aQ
In-Reply-To: <A3D79EAB-904C-4A16-95FB-19D677919B8F@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>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581


Antone Roundy wrote:
> With respect to the issue of aggregate feeds, I had thought
> that the existence of an atom:source element at the entry
> level blocked any "inheritance" of the feed metadata, but
> looking at RFC 4287, I don't see that explicitly stated.
	It's not explicit, but it is implicit. The <source/> element
preserves the entry's feed metadata. Thus, to find the feed metadata
associated with an entry which has an atom:source, you should look to the
preserved data in the atom:source element (or the source feed itself...) --
you should NOT look to the metadata of the feed within which you found the
entry.
	Atom:source says, essentially: "This entry is not of this feed. It
is foreign and should be interpreted as such." Thus, the feed metadata of
the containing feed should never be allowed to leak into the interpretation
of an entry which contains an atom:source. To do so would make syndication,
aggregation, etc. a complete mess.

	bob wyman





From owner-atom-syntax@mail.imc.org Wed Sep 06 20:08:22 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GL7RO-0000Dr-Jj
	for atompub-archive@lists.ietf.org; Wed, 06 Sep 2006 20:08:22 -0400
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1GL7RJ-0001r8-3g
	for atompub-archive@lists.ietf.org; Wed, 06 Sep 2006 20:08:22 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k86NnQ5c010669;
	Wed, 6 Sep 2006 16:49:26 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id k86NnQKP010668;
	Wed, 6 Sep 2006 16:49:26 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mtaout01-winn.ispmail.ntl.com (mtaout01-winn.ispmail.ntl.com [81.103.221.47])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k86NnF0S010621
	for <atom-syntax@imc.org>; Wed, 6 Sep 2006 16:49:25 -0700 (MST)
	(envelope-from djpowell@djpowell.net)
Received: from aamtaout01-winn.ispmail.ntl.com ([81.103.221.35])
          by mtaout01-winn.ispmail.ntl.com with ESMTP
          id <20060906234909.OMJS15018.mtaout01-winn.ispmail.ntl.com@aamtaout01-winn.ispmail.ntl.com>;
          Thu, 7 Sep 2006 00:49:09 +0100
Received: from cpc1-stok1-0-0-cust704.bagu.cable.ntl.com ([86.4.230.193])
          by aamtaout01-winn.ispmail.ntl.com with ESMTP
          id <20060906234909.OMHS644.aamtaout01-winn.ispmail.ntl.com@cpc1-stok1-0-0-cust704.bagu.cable.ntl.com>;
          Thu, 7 Sep 2006 00:49:09 +0100
Date: Thu, 7 Sep 2006 00:49:05 +0100
From: David Powell <djpowell@djpowell.net>
X-Mailer: The Bat! (v3.73 Release Candidate 1) Professional
X-Priority: 3 (Normal)
Message-ID: <1525967428.20060907004905@djpowell.net>
To: Thomas Roessler <roessler@does-not-exist.org>
CC: atom-syntax <atom-syntax@imc.org>
Subject: Re: atom license extension (Re: [cc-tab] *important* heads up)
In-Reply-To: <20060906103813.GS12632@raktajino.does-not-exist.org>
References: <44FD8F55.2010609@mit.edu> <1157478767.18377.47.camel@localhost.localdomain> <1157482144.18377.75.camel@localhost.localdomain> <20060905193613.GX12632@raktajino.does-not-exist.org> <44FDF60A.1010508@gmail.com> <20060906092847.GN12632@raktajino.does-not-exist.org> <20060906102124.GB7464@klangraum> <20060906103813.GS12632@raktajino.does-not-exist.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>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69



Wednesday, September 6, 2006, 11:38:13 AM, you wrote:

> So, here's the proposal:

> - Use <link rel="license"/> for entry licenses -- either on the feed
>   level, setting a default analogous to what atom:rights does, or on
>   the element level.

I think that there are data modelling issues with this approach. I
don't think that the inheritance of extensions from the 'feed
document', to the entries contained within that document is supported
by the spec, nor would it be likely to be supported by typical
implementations of stateful feed stores, frameworks and APIs.

Feeds and entries are seperate entities with seperate life-cycles.
Stateful feed platforms, such as the Windows feed platform,
typically store a single instance of feed metadata, and a single
instance of entry metadata.

When, for example, a feed title changes, the change applies to the
feed as a whole; it isn't localised to only apply to the entries that
were present in that feed document at the time of the change, because
each entry doesn't typically store its own private copy of feed
metadata.

Implementors can cope with the inheritance of atom:rights and
atom:author, because it is explicitly described in the spec, and
implementors know that they must implement the inheritance at the
document parsing stage, and apply the feed-level data to the entry
before storing the entry before they attempt to store the entries in a
database or whatever, but implementations cannot be expected to apply
all feed-level extensions to the entries that they were transmitted
with, just in case any of them might expect to implement feed document
inheritance.

Feed properties are properties of the feed, not the feed document. An
extension can't implement atom:rights/atom:author style inheritance
from the feed document to the contained entries.


-- 
Dave




From owner-atom-syntax@mail.imc.org Thu Sep 07 01:11:43 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GLCAx-0007XC-FL
	for atompub-archive@lists.ietf.org; Thu, 07 Sep 2006 01:11:43 -0400
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1GLCAw-0004Xn-3a
	for atompub-archive@lists.ietf.org; Thu, 07 Sep 2006 01:11:43 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k874uVQW033952;
	Wed, 6 Sep 2006 21:56:31 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id k874uVnQ033951;
	Wed, 6 Sep 2006 21:56:31 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from homer.w3.org (homer.w3.org [128.30.52.30])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k874uToV033945
	for <atom-syntax@imc.org>; Wed, 6 Sep 2006 21:56:30 -0700 (MST)
	(envelope-from karl@w3.org)
Received: from [127.0.0.1] (homer.w3.org [128.30.52.30])
	by homer.w3.org (Postfix) with ESMTP id 246B64F004;
	Thu,  7 Sep 2006 00:56:25 -0400 (EDT)
In-Reply-To: <44FEF751.5080203@aol.net>
References: <44FEF751.5080203@aol.net>
Mime-Version: 1.0 (Apple Message framework v752.2)
Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed
Message-Id: <19ED67F9-FDCE-44CD-8AD9-F9B436E98D2E@w3.org>
Cc: Wendy Seltzer <wendy@seltzer.org>,
        Mike Linksvayer <ml@creativecommons.org>, Ben Adida <ben@mit.edu>,
        Lisa Dusseault <lisa@osafoundation.org>,
        atom-syntax Syntax <atom-syntax@imc.org>
From: Karl Dubost <karl@w3.org>
Subject: Re: atom license extension (Re: [cc-tab] *important* heads up)
Date: Thu, 7 Sep 2006 13:55:53 +0900
To: John Panzer <jpanzer@aol.net>
X-Mailer: Apple Mail (2.752.2)
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k874uUoV033946
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id k874uVQW033952
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22



Le 7 sept. 06 =E0 01:29, John Panzer a =E9crit :
> This is a critical point.  Without this, implementors cannot safely =20
> ignore licenses they don't understand (falling back to things like =20
> "fair use" if they can't find any licenses that grant additional =20
> copying rights).  This means that implementors would likely have to =20
> drop feeds containing new licenses on the floor, meaning that new =20
> license schemes would never be deployed.

People with legal background will confirm or not, but "fair use" =20
doesn't exist in the same way in all countries.

Offering a mechanism to provide licensing information is good.
Encouraging a *legal* fallback mechanism is bad, very bad.

IMHO, when the implementors do not understand the licenses, they have =20
no rights to do things with content (because it's highly dependant of =20
local laws)

--=20
Karl Dubost - http://www.w3.org/People/karl/
W3C Conformance Manager, QA Activity Lead
   QA Weblog - http://www.w3.org/QA/
      *** Be Strict To Be Cool ***






From owner-atom-syntax@mail.imc.org Thu Sep 07 10:00:16 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GLKQS-0007xf-BR
	for atompub-archive@lists.ietf.org; Thu, 07 Sep 2006 10:00:16 -0400
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1GLKQN-0007lw-UI
	for atompub-archive@lists.ietf.org; Thu, 07 Sep 2006 10:00:16 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k87DVeTd087248;
	Thu, 7 Sep 2006 06:31:40 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id k87DVeEc087247;
	Thu, 7 Sep 2006 06:31:40 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mail3.sea5.speakeasy.net (mail3.sea5.speakeasy.net [69.17.117.5])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k87DVbAE087186
	for <atom-syntax@imc.org>; Thu, 7 Sep 2006 06:31:40 -0700 (MST)
	(envelope-from elharo@metalab.unc.edu)
Received: (qmail 11703 invoked from network); 7 Sep 2006 13:31:32 -0000
Received: from dsl254-067-087.nyc1.dsl.speakeasy.net (HELO [192.168.254.100]) (elharo@[216.254.67.87])
          (envelope-sender <elharo@metalab.unc.edu>)
          by mail3.sea5.speakeasy.net (qmail-ldap-1.03) with AES256-SHA encrypted SMTP
          for <atom-syntax@imc.org>; 7 Sep 2006 13:31:31 -0000
Message-ID: <45001F33.7090000@metalab.unc.edu>
Date: Thu, 07 Sep 2006 09:31:31 -0400
From: Elliotte Harold <elharo@metalab.unc.edu>
User-Agent: Thunderbird 1.5.0.5 (Macintosh/20060719)
MIME-Version: 1.0
To: atom-syntax Syntax <atom-syntax@imc.org>
Subject: Re: atom license extension (Re: [cc-tab] *important* heads up)
References: <44FEF751.5080203@aol.net> <19ED67F9-FDCE-44CD-8AD9-F9B436E98D2E@w3.org>
In-Reply-To: <19ED67F9-FDCE-44CD-8AD9-F9B436E98D2E@w3.org>
Content-Type: text/plain; charset=UTF-8; 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>
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id k87DVeTd087248
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 79899194edc4f33a41f49410777972f8


Karl Dubost wrote:

> IMHO, when the implementors do not understand the licenses, they have n=
o=20
> rights to do things with content (because it's highly dependant of loca=
l=20
> laws)

Ignorance of the law is no excuse. Implementors have the rights they=20
have under the applicable set of laws, irrespective of whether or not=20
they understand those rights.

--=20
=EF=BB=BFElliotte Rusty Harold  elharo@metalab.unc.edu
Java I/O 2nd Edition Just Published!
http://www.cafeaulait.org/books/javaio2/
http://www.amazon.com/exec/obidos/ISBN=3D0596527500/ref=3Dnosim/cafeaulai=
tA/




From owner-atom-syntax@mail.imc.org Thu Sep 07 10:57:24 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GLLJk-00037x-DY
	for atompub-archive@lists.ietf.org; Thu, 07 Sep 2006 10:57:24 -0400
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1GLLJf-0000vV-0N
	for atompub-archive@lists.ietf.org; Thu, 07 Sep 2006 10:57:24 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k87EOrqm092196;
	Thu, 7 Sep 2006 07:24:53 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id k87EOrlJ092195;
	Thu, 7 Sep 2006 07:24:53 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mcom.com (c3po.aoltw.net [64.236.137.25])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k87EOoO2092181
	for <atom-syntax@imc.org>; Thu, 7 Sep 2006 07:24:53 -0700 (MST)
	(envelope-from jpanzer@aol.net)
Received: from [10.169.184.10] (sera-10-169-184-10.nscp.aoltw.net [10.169.184.10])
	by mcom.com (8.10.0/8.10.0) with ESMTP id k87EMaW07742;
	Thu, 7 Sep 2006 07:22:36 -0700 (PDT)
Message-ID: <45002B2C.4090206@aol.net>
Date: Thu, 07 Sep 2006 07:22:36 -0700
From: John Panzer <jpanzer@aol.net>
User-Agent: Mozilla Thunderbird 1.0RC1 (Windows/20041201)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: karl@w3.org
CC: John Panzer <jpanzer@aol.net>, Wendy Seltzer <wendy@seltzer.org>,
        Mike Linksvayer <ml@creativecommons.org>, Ben Adida <ben@mit.edu>,
        Lisa Dusseault <lisa@osafoundation.org>,
        atom-syntax Syntax <atom-syntax@imc.org>
Subject: Re: atom license extension (Re: [cc-tab] *important* heads up)
References: <44FEF751.5080203@aol.net> <19ED67F9-FDCE-44CD-8AD9-F9B436E98D2E@w3.org>
In-Reply-To: <19ED67F9-FDCE-44CD-8AD9-F9B436E98D2E@w3.org>
Content-Type: text/plain; charset=ISO-8859-1; 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>
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id k87EOrqm092196
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465


karl@w3.org wrote:

>
>
> Le 7 sept. 06 =E0 01:29, John Panzer a =E9crit :
>
>> This is a critical point.  Without this, implementors cannot safely =20
>> ignore licenses they don't understand (falling back to things like =20
>> "fair use" if they can't find any licenses that grant additional =20
>> copying rights).  This means that implementors would likely have to =20
>> drop feeds containing new licenses on the floor, meaning that new =20
>> license schemes would never be deployed.
>
>
> People with legal background will confirm or not, but "fair use" =20
> doesn't exist in the same way in all countries.
>
> Offering a mechanism to provide licensing information is good.
> Encouraging a *legal* fallback mechanism is bad, very bad.
>
> IMHO, when the implementors do not understand the licenses, they have =20
> no rights to do things with content (because it's highly dependant of =20
> local laws)
>
That's why I said 'things like' "fair use".  Our legal department has=20
been having fun with this topic over the past several months.  I do=20
agree with you that encouraging people to provide licenses is good.  I=20
think that there are fallback mechanisms whether or not we encourage=20
them.  I think that a fallback mechanism -- implied rights to copy for=20
limited purposes -- is a good thing, and whatever gets specified should=20
not work against it.  It's an unfortunate fact that the available=20
mechanisms are 'squishy' and vary with local laws, but they are better=20
than nothing, which seems to be what you advocate.

More practically, if every feed reader and processor has to be modified=20
to understand a license before the license can be used in published=20
feeds, the ability to deploy and experiment with licenses will be=20
drastically reduced.  Which drastically reduces the utility of having=20
licenses.

(Let's say that  Doc Searls somehow discovers a license that would deny=20
sploggers more than implied rights to his content while allowing liberal=20
use for others[1], and deploys it.  Are you saying that all of his=20
readers' feed software would have to drop his feed content until they're=20
upgraded to understand the license?)

[1] http://doc.weblogs.com/2006/08/28





From owner-atom-syntax@mail.imc.org Thu Sep 07 17:43:20 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GLRea-000271-QB
	for atompub-archive@lists.ietf.org; Thu, 07 Sep 2006 17:43:20 -0400
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1GLReZ-000694-9o
	for atompub-archive@lists.ietf.org; Thu, 07 Sep 2006 17:43:20 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k87LSCp7033573;
	Thu, 7 Sep 2006 14:28:12 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id k87LSCbo033572;
	Thu, 7 Sep 2006 14:28:12 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from omr8.networksolutionsemail.com (omr8.networksolutionsemail.com [205.178.146.58])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k87LSAPi033565
	for <atom-syntax@imc.org>; Thu, 7 Sep 2006 14:28:11 -0700 (MST)
	(envelope-from bob@wyman.us)
Received: from mail.networksolutionsemail.com (ns-omr8.mgt.netsol.com [10.49.6.71])
	by omr8.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id k87LS86w026874
	for <atom-syntax@imc.org>; Thu, 7 Sep 2006 17:28:09 -0400
Received: (qmail 18351 invoked by uid 78); 7 Sep 2006 21:28:08 -0000
Received: from unknown (HELO BOBSLAPTOP) (162.83.157.76)
  by ns-omr8.lb.hosting.dc2.netsol.com with SMTP; 7 Sep 2006 21:28:08 -0000
From: "Bob Wyman" <bob@wyman.us>
To: "'John Panzer'" <jpanzer@aol.net>, <karl@w3.org>
Cc: "'Wendy Seltzer'" <wendy@seltzer.org>,
        "'Mike Linksvayer'" <ml@creativecommons.org>,
        "'Ben Adida'" <ben@mit.edu>,
        "'Lisa Dusseault'" <lisa@osafoundation.org>,
        "'atom-syntax Syntax'" <atom-syntax@imc.org>
Subject: RE: atom license extension (Re: [cc-tab] *important* heads up)
Date: Thu, 7 Sep 2006 17:28:04 -0400
Message-ID: <009001c6d2c4$814ae530$1001000a@BOBSLAPTOP>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962
Thread-Index: AcbSj8jwb0jMDDO4S+qapK7G+fW8jgAL79Qw
In-Reply-To: <45002B2C.4090206@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>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe


John Panzer asks of Karl Dubost:
> (Let's say that  Doc Searls somehow discovers a license that
> would deny sploggers more than implied rights to his content
> while allowing liberal use for others[1], and deploys it.
>  Are you saying that all of his readers' feed software would
> have to drop his feed content until they're upgraded to
> understand the license?) [1] http://doc.weblogs.com/2006/08/28
	I think John's question can be (aggressively) rephrased as: "Can Doc
Searls, by inserting a license in his feed, 'poison' the entire syndication
system that we've built over the last few years?" (i.e. Can he do things
that make it unsafe or illegal for people to do things which the syndication
system was intentionally built to permit and which he knew were being done
before he willingly inserted his content into the syndication network?) I
don't think so.
	As argued in other messages, I strongly believe that we should not
do anything that hinders or conflicts with the establishment or recognition
of a limited implied license to syndicate content which is formatted using
RSS/Atom and is made openly available on the network. (An interesting
question, of course, would be: "What does it mean to 'syndicate'?")
	In any case, there is a general problem of "proper notice" here. As
mentioned before, there is nothing special about an optional IETF protocol
extension. This subject of inserting licenses in content should be discussed
in a general sense -- not limited to this specific protocol extension. 
	A vital question to ask is: What is proper notice of the presence of
a license? No IETF standard has the force of law. Readers are not obligated
to understand or even take note of the license links. Thus, no one using it
should be able to have any expectation that readers will take note of it any
more than they would of many other possible means of inserting licenses or
references to them in content. Publishers and consumers should both be
working on the assumption that normal copyright exists (i.e *all rights
reserved*) except where there are fair use privileges of implied licenses
that weaken the *all rights* default.)
	If we were to allow or encourage any one mechanism to associate
restrictive licenses with content, we establish a precedent that would allow
or encourage others as well. Any other "standards group" or informal
collection of one or more persons could decide to define a new mechanism --
just like the IETF did. At that point, no reader could safely consume
content since no matter how many mechanisms they supported there might be
some others that they didn't know about. The issue here is about proper
notice... How can we obligate folk to respect licenses that they have no
means of discovering?
	We should also ask: "At what point does a restrictive license become
operative?" Imagine that I decided that reading (copying) of my feeds by
commercial organizations was to be prohibited. Could I bar such copying by
putting a license in the content itself? Of course, if I did, that means
that in order to discover that copying was not permitted the reader would
have to actually do the thing which is prohibited. Clearly, even if there
was some way to put effective restrictive licenses in content, there would
have to remain some "implied license" exceptions to the *all rights"
provision of copyright.
	We are all best served by an assumption that copyright leaves "all
rights" reserved to the publisher and that only "fair use," "limited implied
license to syndicate," and "explicit license grants (like CC)" limit the
totality of those rights. With this in mind it might be best to change from
a "license" link to a "rights-grant" link... In other words, frame this link
type as something which can *only* be used to broaden rights, not restrict
them.

	bob wyman






From owner-atom-syntax@mail.imc.org Thu Sep 07 23:10:01 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GLWkj-0003py-DX
	for atompub-archive@lists.ietf.org; Thu, 07 Sep 2006 23:10:01 -0400
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1GLWke-00053L-AB
	for atompub-archive@lists.ietf.org; Thu, 07 Sep 2006 23:10:01 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k882qZ9G057665;
	Thu, 7 Sep 2006 19:52:35 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id k882qZ5F057664;
	Thu, 7 Sep 2006 19:52:35 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mcom.com (c3po.aoltw.net [64.236.137.25])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k882qTik057617
	for <atom-syntax@imc.org>; Thu, 7 Sep 2006 19:52:34 -0700 (MST)
	(envelope-from jpanzer@aol.net)
Received: from [192.168.1.4] (sera-10-169-184-37.nscp.aoltw.net [10.169.184.37])
	by mcom.com (8.10.0/8.10.0) with ESMTP id k882p5W15701;
	Thu, 7 Sep 2006 19:51:10 -0700 (PDT)
Message-ID: <4500DA90.1020507@aol.net>
Date: Thu, 07 Sep 2006 19:50:56 -0700
From: John Panzer <jpanzer@aol.net>
User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Wendy Seltzer <wendy@seltzer.org>
CC: Bob Wyman <bob@wyman.us>, "'James M Snell'" <jasnell@gmail.com>,
        "'Thomas Roessler'" <tlr@w3.org>,
        "'Mike Linksvayer'" <ml@creativecommons.org>,
        "'Ben Adida'" <ben@mit.edu>,
        "'Lisa Dusseault'" <lisa@osafoundation.org>,
        "'atom-syntax'" <atom-syntax@imc.org>
Subject: Re: atom license extension (Re: [cc-tab] *important* heads up)
References: <44FEF751.5080203@aol.net> <7.0.0.10.2.20060906135801.05b1d0e8@seltzer.com>
In-Reply-To: <7.0.0.10.2.20060906135801.05b1d0e8@seltzer.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>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c


Wendy Seltzer wrote:

> ...
>
> The concern about limiting implied licenses is important, though.  By 
> definition, an implied license is one that's presumed from the context 
> of an offering and by the absence of a contrary explicit license.  If 
> as a factual matter, many people have been acting based on implied 
> licenses of broader scope than either fair use or what would be chosen 
> in an explicitly linked license, then you might say it's better not to 
> provide this encouragement to link licenses at all (and hoping that 
> time and general practice will morph those implied terms into fair uses).
>
> If the rfc encourages people to add licenses, it opens up the 
> possibility that their explicit terms will contradict and override 
> what has previously been implied.

That's a worrying Heisenburg effect.

>> This is a critical point.  Without this, implementors cannot safely 
>> ignore licenses they don't understand (falling back to things like 
>> "fair use" if they can't find any licenses that grant additional 
>> copying rights).  This means that implementors would likely have to 
>> drop feeds containing new licenses on the floor, meaning that new 
>> license schemes would never be deployed.
>>
>>>
>>> ...
>>>     Thus, it would seem that the only effective use of the license link
>>> is to grant rights not to restrict them.
>>
>> Yes.  Given the current murky and complicated legal situation with 
>> implied licenses, fair use, etc., granting explicit and well defined 
>> rights is a huge win for everyone.
>
>
> I don't think there's a legal mechanism for telling people "you may 
> only use this format if you grant a license equally or more permissive 
> than X."  (at least none short of patent claims on the format itself...)

No, but I think there may be a technical mechanism for saying "this 
particular extension only lets you grant rights with each new license 
link, not take them away":

> ...
>
>> How about (IANAL of course):
>>
>> "Nor can a license.... restrict or remove any implied copy or usage 
>> rights which would otherwise exist in the absence of the license."
>>
>> The intent being that adding a license, or a new type of license, is 
>> always safe:  If what you're doing with content is allowable, if the 
>> feed provider adds a license, it is still allowable.
>>
There is a parallel with the principle of substitutability [1] in 
software engineering, which allows extension while maintaining desirable 
invariants (in this case, the ability to what one would naturally expect 
to do with a feed).

[1] http://en.wikipedia.org/wiki/Liskov_substitution_principle

-John Panzer
http://abstractioneer.org




From owner-atom-syntax@mail.imc.org Fri Sep 08 11:41:52 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GLiUK-0001cV-Lq
	for atompub-archive@lists.ietf.org; Fri, 08 Sep 2006 11:41:52 -0400
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1GLiUJ-00089v-2n
	for atompub-archive@lists.ietf.org; Fri, 08 Sep 2006 11:41:52 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k88FMA2P019215;
	Fri, 8 Sep 2006 08:22:10 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id k88FMACo019214;
	Fri, 8 Sep 2006 08:22:10 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.233])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k88FM8GC019208
	for <atom-syntax@imc.org>; Fri, 8 Sep 2006 08:22:09 -0700 (MST)
	(envelope-from jasnell@gmail.com)
Received: by wx-out-0506.google.com with SMTP id t12so710796wxc
        for <atom-syntax@imc.org>; Fri, 08 Sep 2006 08:22:07 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding;
        b=nrGm6GGVcarxrdBN13I8rcBKBFSslKZDr4qdJJ6OaznIX2WjQBBXHcEDonQnKVAypwnDdXlcGW28uJwRttLuEw+uKFgRXFYiWXtfjjT4oF/nLdP1vrWLXs9lyB2O2fyDtrxCZVuIu4wH1YfQ5FHKU8WLXkpl530cRoolDH/j6vc=
Received: by 10.70.87.11 with SMTP id k11mr183309wxb;
        Fri, 08 Sep 2006 08:22:07 -0700 (PDT)
Received: from ?192.168.1.104? ( [67.181.218.96])
        by mx.gmail.com with ESMTP id h9sm2807820wxd.2006.09.08.08.22.04;
        Fri, 08 Sep 2006 08:22:06 -0700 (PDT)
Message-ID: <45018A97.3030809@gmail.com>
Date: Fri, 08 Sep 2006 08:21:59 -0700
From: James M Snell <jasnell@gmail.com>
User-Agent: Thunderbird 1.5.0.5 (X11/20060719)
MIME-Version: 1.0
To: Bob Wyman <bob@wyman.us>
CC: "'John Panzer'" <jpanzer@aol.net>, karl@w3.org,
        "'Wendy Seltzer'" <wendy@seltzer.org>,
        "'Mike Linksvayer'" <ml@creativecommons.org>,
        "'Ben Adida'" <ben@mit.edu>,
        "'Lisa Dusseault'" <lisa@osafoundation.org>,
        "'atom-syntax Syntax'" <atom-syntax@imc.org>
Subject: Re: atom license extension (Re: [cc-tab] *important* heads up)
References: <009001c6d2c4$814ae530$1001000a@BOBSLAPTOP>
In-Reply-To: <009001c6d2c4$814ae530$1001000a@BOBSLAPTOP>
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>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5


I think the discussion around this has been absolutely excellent.  Lots
of very good information and perspectives.  At this point I need to stew
over things for a few days and think about how to proceed with the
extension.

In addition to the several technical changes that I may end up making to
the specification, I am thinking now that a detailed description of the
non-technical issues surrounding this spec would be a great addition to
the document.  I'm just not sure I'm qualified to write such a thing myself.

- James

Bob Wyman wrote:
> John Panzer asks of Karl Dubost:
>> (Let's say that  Doc Searls somehow discovers a license that
>> would deny sploggers more than implied rights to his content
>> while allowing liberal use for others[1], and deploys it.
>>  Are you saying that all of his readers' feed software would
>> have to drop his feed content until they're upgraded to
>> understand the license?) [1] http://doc.weblogs.com/2006/08/28
> 	I think John's question can be (aggressively) rephrased as: "Can Doc
> Searls, by inserting a license in his feed, 'poison' the entire syndication
> system that we've built over the last few years?" (i.e. Can he do things
> that make it unsafe or illegal for people to do things which the syndication
> system was intentionally built to permit and which he knew were being done
> before he willingly inserted his content into the syndication network?) I
> don't think so.
> 	As argued in other messages, I strongly believe that we should not
> do anything that hinders or conflicts with the establishment or recognition
> of a limited implied license to syndicate content which is formatted using
> RSS/Atom and is made openly available on the network. (An interesting
> question, of course, would be: "What does it mean to 'syndicate'?")
> 	In any case, there is a general problem of "proper notice" here. As
> mentioned before, there is nothing special about an optional IETF protocol
> extension. This subject of inserting licenses in content should be discussed
> in a general sense -- not limited to this specific protocol extension. 
> 	A vital question to ask is: What is proper notice of the presence of
> a license? No IETF standard has the force of law. Readers are not obligated
> to understand or even take note of the license links. Thus, no one using it
> should be able to have any expectation that readers will take note of it any
> more than they would of many other possible means of inserting licenses or
> references to them in content. Publishers and consumers should both be
> working on the assumption that normal copyright exists (i.e *all rights
> reserved*) except where there are fair use privileges of implied licenses
> that weaken the *all rights* default.)
> 	If we were to allow or encourage any one mechanism to associate
> restrictive licenses with content, we establish a precedent that would allow
> or encourage others as well. Any other "standards group" or informal
> collection of one or more persons could decide to define a new mechanism --
> just like the IETF did. At that point, no reader could safely consume
> content since no matter how many mechanisms they supported there might be
> some others that they didn't know about. The issue here is about proper
> notice... How can we obligate folk to respect licenses that they have no
> means of discovering?
> 	We should also ask: "At what point does a restrictive license become
> operative?" Imagine that I decided that reading (copying) of my feeds by
> commercial organizations was to be prohibited. Could I bar such copying by
> putting a license in the content itself? Of course, if I did, that means
> that in order to discover that copying was not permitted the reader would
> have to actually do the thing which is prohibited. Clearly, even if there
> was some way to put effective restrictive licenses in content, there would
> have to remain some "implied license" exceptions to the *all rights"
> provision of copyright.
> 	We are all best served by an assumption that copyright leaves "all
> rights" reserved to the publisher and that only "fair use," "limited implied
> license to syndicate," and "explicit license grants (like CC)" limit the
> totality of those rights. With this in mind it might be best to change from
> a "license" link to a "rights-grant" link... In other words, frame this link
> type as something which can *only* be used to broaden rights, not restrict
> them.
> 
> 	bob wyman
> 
> 
> 
> 




From owner-atom-syntax@mail.imc.org Mon Sep 11 07:05:29 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GMjbV-00039U-L9
	for atompub-archive@lists.ietf.org; Mon, 11 Sep 2006 07:05:29 -0400
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1GMjbT-0008JI-99
	for atompub-archive@lists.ietf.org; Mon, 11 Sep 2006 07:05:29 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k8BAf7F8078225;
	Mon, 11 Sep 2006 03:41:07 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id k8BAf7h2078224;
	Mon, 11 Sep 2006 03:41:07 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from kamino.does-not-exist.org (kamino.does-not-exist.org [217.160.221.198])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k8BAf5ex078215
	for <atom-syntax@imc.org>; Mon, 11 Sep 2006 03:41:06 -0700 (MST)
	(envelope-from roessler@does-not-exist.org)
Received: from raktajino.does-not-exist.org (ip-83-99-50-11.dyn.luxdsl.pt.lu [83.99.50.11])
	(using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits))
	(No client certificate requested)
	by kamino.does-not-exist.org (Postfix) with ESMTP
	id 06E7119372F; Mon, 11 Sep 2006 12:40:32 +0200 (CEST)
Received: from roessler by raktajino.does-not-exist.org with local (Exim 4.62)
	(envelope-from <roessler@does-not-exist.org>)
	id 1GMjD2-000309-F3; Mon, 11 Sep 2006 12:40:12 +0200
Date: Mon, 11 Sep 2006 12:40:10 +0200
From: Thomas Roessler <roessler@does-not-exist.org>
To: James M Snell <jasnell@gmail.com>
Cc: Bob Wyman <bob@wyman.us>, "'John Panzer'" <jpanzer@aol.net>, karl@w3.org,
        "'Wendy Seltzer'" <wendy@seltzer.org>,
        "'Mike Linksvayer'" <ml@creativecommons.org>,
        "'Ben Adida'" <ben@mit.edu>,
        "'Lisa Dusseault'" <lisa@osafoundation.org>,
        "'atom-syntax Syntax'" <atom-syntax@imc.org>
Subject: Re: atom license extension (Re: [cc-tab] *important* heads up)
Message-ID: <20060911104009.GD9541@raktajino.does-not-exist.org>
Mail-Followup-To: James M Snell <jasnell@gmail.com>,
	Bob Wyman <bob@wyman.us>, 'John Panzer' <jpanzer@aol.net>,
	karl@w3.org, 'Wendy Seltzer' <wendy@seltzer.org>,
	'Mike Linksvayer' <ml@creativecommons.org>,
	'Ben Adida' <ben@mit.edu>, 'Lisa Dusseault' <lisa@osafoundation.org>,
	'atom-syntax Syntax' <atom-syntax@imc.org>
References: <009001c6d2c4$814ae530$1001000a@BOBSLAPTOP> <45018A97.3030809@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <45018A97.3030809@gmail.com>
User-Agent: Mutt/1.5.13 (2006-09-01)
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25


On 2006-09-08 08:21:59 -0700, James M Snell wrote:

> I think the discussion around this has been absolutely excellent.
> Lots of very good information and perspectives.  At this point I
> need to stew over things for a few days and think about how to
> proceed with the extension.

The last call for this spec is ending today...  I'm wondering a bit
what the next step (if any) between you and Lisa (as the shepherding
AD) needs to be in order to make sure that this goes as you intend
it to go.

-- 
Thomas Roessler   <roessler@does-not-exist.org>




From owner-atom-syntax@mail.imc.org Mon Sep 11 07:49:31 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GMkI7-0005Cs-8J
	for atompub-archive@lists.ietf.org; Mon, 11 Sep 2006 07:49:31 -0400
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1GMkI5-0005hK-TD
	for atompub-archive@lists.ietf.org; Mon, 11 Sep 2006 07:49:31 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k8BBRGqu082559;
	Mon, 11 Sep 2006 04:27:16 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id k8BBRGFe082558;
	Mon, 11 Sep 2006 04:27:16 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from ixion.tartarus.org (ixion.tartarus.org [82.211.108.121])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k8BBRDNg082551
	for <atom-syntax@imc.org>; Mon, 11 Sep 2006 04:27:15 -0700 (MST)
	(envelope-from james@ixion.tartarus.org)
Received: from james by ixion.tartarus.org with local (Exim 3.36 #1 (Debian))
	for atom-syntax@imc.org
	id 1GMjwW-0004nu-00; Mon, 11 Sep 2006 12:27:12 +0100
Date: Mon, 11 Sep 2006 12:27:12 +0100
From: James Aylett <james@tartarus.org>
To: atom-syntax@imc.org
Subject: Private extensions and relation to atom elements
Message-ID: <20060911112712.GF17947@tartarus.org>
Mail-Followup-To: James Aylett <james@tartarus.org>, atom-syntax@imc.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.9i
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 97adf591118a232206bdb5a27b217034


We've run across a situation where we want to annotate an atom:icon
with a title. Currently we're doing the following, as something that
Feed Validator is happy with, but doesn't feel right:

----------------------------------------------------------------------
  <atom:icon>uri:to/icon</atom:icon>
  <myns:icon-title xml:lang='en' xmlns:myns='...'>My icon
    title</myns:icon-title>
----------------------------------------------------------------------

It doesn't express the relationship directly. The way that would be
most natural in XML doesn't seem to be allowed (because we don't have
extension attributes):

----------------------------------------------------------------------
  <atom:icon myns:title='My icon title' ...>uri:to/icon</atom:icon>
----------------------------------------------------------------------

and all other ways I can think of involve extension elements in the
wrong place.

Anyone have another suggestion on how to approach this? Or would we be
better off adding our own <myns:icon/> which we can decorate with
titles, languages and whatever to our heart's content, even though
it's redundant to some extent?

James

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




From owner-atom-syntax@mail.imc.org Mon Sep 11 10:47:36 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GMn4S-0007ut-LC
	for atompub-archive@lists.ietf.org; Mon, 11 Sep 2006 10:47:36 -0400
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1GMn4R-0000C8-5Z
	for atompub-archive@lists.ietf.org; Mon, 11 Sep 2006 10:47:36 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k8BEOgdI098752;
	Mon, 11 Sep 2006 07:24:42 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id k8BEOgHi098751;
	Mon, 11 Sep 2006 07:24:42 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.237])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k8BEOfki098743
	for <atom-syntax@imc.org>; Mon, 11 Sep 2006 07:24:41 -0700 (MST)
	(envelope-from jasnell@gmail.com)
Received: by wx-out-0506.google.com with SMTP id t12so1693138wxc
        for <atom-syntax@imc.org>; Mon, 11 Sep 2006 07:24:40 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding;
        b=TAe9qTFMyG3JEzD64hDU9hiI8HwMZHVVw/Z7Gv5Cm8x/0xgVmsPv0+KEv7ITGlLFwLUceRz7JUklK2GckyTcHvG6AR6MPKUN7YEFt39K8oeG0pvt+xlU1IwVybKxbiWk4olDGagsUBvjgFgxNgUv29ZFlUgD88MzYuCQdNH7gOM=
Received: by 10.70.78.8 with SMTP id a8mr6236143wxb;
        Mon, 11 Sep 2006 07:24:40 -0700 (PDT)
Received: from ?192.168.1.104? ( [67.181.218.96])
        by mx.gmail.com with ESMTP id h34sm3056756wxd.2006.09.11.07.24.38;
        Mon, 11 Sep 2006 07:24:40 -0700 (PDT)
Message-ID: <450571A3.3050009@gmail.com>
Date: Mon, 11 Sep 2006 07:24:35 -0700
From: James M Snell <jasnell@gmail.com>
User-Agent: Thunderbird 1.5.0.5 (X11/20060719)
MIME-Version: 1.0
To: James M Snell <jasnell@gmail.com>, Bob Wyman <bob@wyman.us>,
        "'John Panzer'" <jpanzer@aol.net>, karl@w3.org,
        "'Wendy Seltzer'" <wendy@seltzer.org>,
        "'Mike Linksvayer'" <ml@creativecommons.org>,
        "'Ben Adida'" <ben@mit.edu>,
        "'Lisa Dusseault'" <lisa@osafoundation.org>,
        "'atom-syntax Syntax'" <atom-syntax@imc.org>
Subject: Re: atom license extension (Re: [cc-tab] *important* heads up)
References: <009001c6d2c4$814ae530$1001000a@BOBSLAPTOP> <45018A97.3030809@gmail.com> <20060911104009.GD9541@raktajino.does-not-exist.org>
In-Reply-To: <20060911104009.GD9541@raktajino.does-not-exist.org>
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>
X-Spam-Score: 1.9 (+)
X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581


I talked with Lisa a bit about this next week.  I'll be working on
iterating the draft based on this conversation and will request another
last call once it's ready to go.

- James

Thomas Roessler wrote:
> On 2006-09-08 08:21:59 -0700, James M Snell wrote:
> 
>> I think the discussion around this has been absolutely excellent.
>> Lots of very good information and perspectives.  At this point I
>> need to stew over things for a few days and think about how to
>> proceed with the extension.
> 
> The last call for this spec is ending today...  I'm wondering a bit
> what the next step (if any) between you and Lisa (as the shepherding
> AD) needs to be in order to make sure that this goes as you intend
> it to go.
> 




From owner-atom-syntax@mail.imc.org Mon Sep 11 10:54:20 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GMnAy-00024Z-U9
	for atompub-archive@lists.ietf.org; Mon, 11 Sep 2006 10:54:20 -0400
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1GMnAx-00025L-I3
	for atompub-archive@lists.ietf.org; Mon, 11 Sep 2006 10:54:20 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k8BERXlm099169;
	Mon, 11 Sep 2006 07:27:33 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id k8BERXn9099168;
	Mon, 11 Sep 2006 07:27:33 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.235])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k8BERW0p099160
	for <atom-syntax@imc.org>; Mon, 11 Sep 2006 07:27:33 -0700 (MST)
	(envelope-from jasnell@gmail.com)
Received: by wx-out-0506.google.com with SMTP id t12so1694033wxc
        for <atom-syntax@imc.org>; Mon, 11 Sep 2006 07:27:32 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding;
        b=qL9g4T823JDCVxXeH8cctKPBDHAR/wv9wYnNVysYHktm/C5qaGd9Odi2Xaah5QxENOBjZqnCotu8kXmCvrNoFJ6cjZxOY7+TSKWau5udxwW/Khx29XYr6qvP1IUby4aKO+QqkE1aoX2wKxLeeMT78HSL6nsHtPohpRxEKssdgY8=
Received: by 10.70.8.20 with SMTP id 20mr6290626wxh;
        Mon, 11 Sep 2006 07:27:31 -0700 (PDT)
Received: from ?192.168.1.104? ( [67.181.218.96])
        by mx.gmail.com with ESMTP id i19sm7331637wxd.2006.09.11.07.27.30;
        Mon, 11 Sep 2006 07:27:31 -0700 (PDT)
Message-ID: <4505724F.4000606@gmail.com>
Date: Mon, 11 Sep 2006 07:27:27 -0700
From: James M Snell <jasnell@gmail.com>
User-Agent: Thunderbird 1.5.0.5 (X11/20060719)
MIME-Version: 1.0
To: James Aylett <james@tartarus.org>, atom-syntax@imc.org
Subject: Re: Private extensions and relation to atom elements
References: <20060911112712.GF17947@tartarus.org>
In-Reply-To: <20060911112712.GF17947@tartarus.org>
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>
X-Spam-Score: 1.9 (+)
X-Scan-Signature: 52e1467c2184c31006318542db5614d5


Using extension attributes is a perfectly legitimate solution.  The one
drawback is that not all implementations will support 'em.

- James

James Aylett wrote:
> We've run across a situation where we want to annotate an atom:icon
> with a title. Currently we're doing the following, as something that
> Feed Validator is happy with, but doesn't feel right:
> 
> ----------------------------------------------------------------------
>   <atom:icon>uri:to/icon</atom:icon>
>   <myns:icon-title xml:lang='en' xmlns:myns='...'>My icon
>     title</myns:icon-title>
> ----------------------------------------------------------------------
> 
> It doesn't express the relationship directly. The way that would be
> most natural in XML doesn't seem to be allowed (because we don't have
> extension attributes):
> 
> ----------------------------------------------------------------------
>   <atom:icon myns:title='My icon title' ...>uri:to/icon</atom:icon>
> ----------------------------------------------------------------------
> 
> and all other ways I can think of involve extension elements in the
> wrong place.
> 
> Anyone have another suggestion on how to approach this? Or would we be
> better off adding our own <myns:icon/> which we can decorate with
> titles, languages and whatever to our heart's content, even though
> it's redundant to some extent?
> 
> James
> 




From owner-atom-syntax@mail.imc.org Mon Sep 11 11:07:34 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GMnNm-0007OP-T5
	for atompub-archive@lists.ietf.org; Mon, 11 Sep 2006 11:07:34 -0400
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1GMnNk-0003uG-HH
	for atompub-archive@lists.ietf.org; Mon, 11 Sep 2006 11:07:34 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k8BEjtxi001531;
	Mon, 11 Sep 2006 07:45:55 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id k8BEjtPu001530;
	Mon, 11 Sep 2006 07:45:55 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from ixion.tartarus.org (ixion.tartarus.org [82.211.108.121])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k8BEjslH001524
	for <atom-syntax@imc.org>; Mon, 11 Sep 2006 07:45:55 -0700 (MST)
	(envelope-from james@ixion.tartarus.org)
Received: from james by ixion.tartarus.org with local (Exim 3.36 #1 (Debian))
	for atom-syntax@imc.org
	id 1GMn2o-0007Xg-00; Mon, 11 Sep 2006 15:45:54 +0100
Date: Mon, 11 Sep 2006 15:45:53 +0100
From: James Aylett <james@tartarus.org>
To: atom-syntax@imc.org
Subject: Re: Private extensions and relation to atom elements
Message-ID: <20060911144553.GK17947@tartarus.org>
Mail-Followup-To: James Aylett <james@tartarus.org>, atom-syntax@imc.org
References: <20060911112712.GF17947@tartarus.org> <4505724F.4000606@gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4505724F.4000606@gmail.com>
User-Agent: Mutt/1.5.9i
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d6b246023072368de71562c0ab503126


On Mon, Sep 11, 2006 at 07:27:27AM -0700, James M Snell wrote:

> Using extension attributes is a perfectly legitimate solution.  The one
> drawback is that not all implementations will support 'em.

That's not a problem, to be honest - we have (amongst other things) a
Flash 'player' for the atom feeds involved, and some clients want a
title alongside the feed icon and/or logo.

Feed Validator gets upset with extension attributes - is it wrong?

James

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




From owner-atom-syntax@mail.imc.org Mon Sep 11 11:31:11 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GMnkd-00025s-FU
	for atompub-archive@lists.ietf.org; Mon, 11 Sep 2006 11:31:11 -0400
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1GMnkb-0006yM-2q
	for atompub-archive@lists.ietf.org; Mon, 11 Sep 2006 11:31:11 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k8BF9aGj005531;
	Mon, 11 Sep 2006 08:09:36 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id k8BF9aLk005530;
	Mon, 11 Sep 2006 08:09:36 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.232])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k8BF9Yo5005493
	for <atom-syntax@imc.org>; Mon, 11 Sep 2006 08:09:34 -0700 (MST)
	(envelope-from jasnell@gmail.com)
Received: by wr-out-0506.google.com with SMTP id i12so236337wra
        for <atom-syntax@imc.org>; Mon, 11 Sep 2006 08:09:33 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding;
        b=ScGl22ZuoQ/OXwL2iV0Mjd719tE5bFgdJjjxW/tysoXImxQROGlQwyqlfWlCYlBwsoo58vopx2DVLP0pPtn0RRMF63Q5kWvq7uxSxu97udisyHnEzqTFekMYoPCHphpx8/x4POFr2tSGM1iRqujwXsPKaq1R4GTlQYF08CW8QRE=
Received: by 10.90.71.12 with SMTP id t12mr1653986aga;
        Mon, 11 Sep 2006 08:09:31 -0700 (PDT)
Received: from ?192.168.1.104? ( [67.181.218.96])
        by mx.gmail.com with ESMTP id 43sm5905036wri.2006.09.11.08.09.31;
        Mon, 11 Sep 2006 08:09:31 -0700 (PDT)
Message-ID: <45057C27.3030800@gmail.com>
Date: Mon, 11 Sep 2006 08:09:27 -0700
From: James M Snell <jasnell@gmail.com>
User-Agent: Thunderbird 1.5.0.5 (X11/20060719)
MIME-Version: 1.0
To: James Aylett <james@tartarus.org>, atom-syntax@imc.org
Subject: Re: Private extensions and relation to atom elements
References: <20060911112712.GF17947@tartarus.org> <4505724F.4000606@gmail.com> <20060911144553.GK17947@tartarus.org>
In-Reply-To: <20060911144553.GK17947@tartarus.org>
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>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb


atom:icon is defined as:

   atomIcon = element atom:icon {
      atomCommonAttributes,
      (atomUri)
   }

atomCommonAttributes is defined as:

   atomCommonAttributes =
      attribute xml:base { atomUri }?,
      attribute xml:lang { atomLanguageTag }?,
      undefinedAttribute*

The Validator should be ignoring any extensions (including attributes)
it is not familiar with so yes, I would say that it's wrong if its
returning an error.  A warning would be appropriate tho given that not
all implementations will be capable of making use of extension attributes.

One additional point, be sure to clearly define whether or not your
title attribute value should be interpreted as plain text or escaped
markup (preferably the former).

- James

James Aylett wrote:
> On Mon, Sep 11, 2006 at 07:27:27AM -0700, James M Snell wrote:
> 
>> Using extension attributes is a perfectly legitimate solution.  The one
>> drawback is that not all implementations will support 'em.
> 
> That's not a problem, to be honest - we have (amongst other things) a
> Flash 'player' for the atom feeds involved, and some clients want a
> title alongside the feed icon and/or logo.
> 
> Feed Validator gets upset with extension attributes - is it wrong?
> 
> James
> 




From owner-atom-syntax@mail.imc.org Mon Sep 11 11:40:06 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GMntG-0005CC-14
	for atompub-archive@lists.ietf.org; Mon, 11 Sep 2006 11:40:06 -0400
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1GMntE-0007YQ-LI
	for atompub-archive@lists.ietf.org; Mon, 11 Sep 2006 11:40:06 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k8BFI16s006895;
	Mon, 11 Sep 2006 08:18:01 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id k8BFI1JZ006894;
	Mon, 11 Sep 2006 08:18:01 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from ixion.tartarus.org (ixion.tartarus.org [82.211.108.121])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k8BFI0dG006887
	for <atom-syntax@imc.org>; Mon, 11 Sep 2006 08:18:01 -0700 (MST)
	(envelope-from james@ixion.tartarus.org)
Received: from james by ixion.tartarus.org with local (Exim 3.36 #1 (Debian))
	for atom-syntax@imc.org
	id 1GMnXs-0007KS-00; Mon, 11 Sep 2006 16:18:00 +0100
Date: Mon, 11 Sep 2006 16:18:00 +0100
From: James Aylett <james@tartarus.org>
To: atom-syntax@imc.org
Subject: Re: Private extensions and relation to atom elements
Message-ID: <20060911151800.GL17947@tartarus.org>
Mail-Followup-To: James Aylett <james@tartarus.org>, atom-syntax@imc.org
References: <20060911112712.GF17947@tartarus.org> <4505724F.4000606@gmail.com> <20060911144553.GK17947@tartarus.org> <45057C27.3030800@gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <45057C27.3030800@gmail.com>
User-Agent: Mutt/1.5.9i
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca


On Mon, Sep 11, 2006 at 08:09:27AM -0700, James M Snell wrote:

> atom:icon is defined as:
> 
>    atomIcon = element atom:icon {
>       atomCommonAttributes,
>       (atomUri)
>    }
> 
> atomCommonAttributes is defined as:
> 
>    atomCommonAttributes =
>       attribute xml:base { atomUri }?,
>       attribute xml:lang { atomLanguageTag }?,
>       undefinedAttribute*

Hmm, I'd misunderstood what undefinedAttribute meant. Or, more likely,
missed it entirely. Thanks :)

> The Validator should be ignoring any extensions (including attributes)
> it is not familiar with so yes, I would say that it's wrong if its
> returning an error.  A warning would be appropriate tho given that not
> all implementations will be capable of making use of extension attributes.

Should the validator have different levels of warning? For instance,
it warns you if you have some iTunes extensions but not others; it
warns you if your RSS uses dates in a strange format that some readers
might not be able to parse; it should warn here. These are all
different: specific application may have problems; general
applications may have problems with a core feature; general
applications may ignore an extension.

(This isn't really the right forum for this, so apologies.)

> One additional point, be sure to clearly define whether or not your
> title attribute value should be interpreted as plain text or escaped
> markup (preferably the former).

Well, it's a private extension, so in practice you're not going to
know if we define it or not :-)

But yeah, point taken and I'll make sure it gets added to our spec
internally.

James

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




From owner-atom-syntax@mail.imc.org Mon Sep 11 11:53:21 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GMo65-0002Yt-Q3
	for atompub-archive@lists.ietf.org; Mon, 11 Sep 2006 11:53:21 -0400
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1GMo62-0000Fy-AV
	for atompub-archive@lists.ietf.org; Mon, 11 Sep 2006 11:53:21 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k8BFZFUP009593;
	Mon, 11 Sep 2006 08:35:15 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id k8BFZFLv009592;
	Mon, 11 Sep 2006 08:35:15 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k8BFZDnA009586
	for <atom-syntax@imc.org>; Mon, 11 Sep 2006 08:35:14 -0700 (MST)
	(envelope-from Tim.Bray@Sun.COM)
Received: from fe-amer-02.sun.com ([192.18.108.176])
	by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k8BFZDYp010380
	for <atom-syntax@imc.org>; Mon, 11 Sep 2006 09:35:13 -0600 (MDT)
Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com
 (Sun Java System Messaging Server 6.2-4.02 (built Sep  9 2005))
 id <0J5F00D01PO01Y00@mail-amer.sun.com> (original mail from Tim.Bray@Sun.COM)
 for atom-syntax@imc.org; Mon, 11 Sep 2006 09:35:13 -0600 (MDT)
Received: from [192.168.1.15] ([216.113.204.64])
 by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep  9
 2005)) with ESMTPSA id <0J5F00MKPPYO9T83@mail-amer.sun.com>; Mon,
 11 Sep 2006 09:35:13 -0600 (MDT)
Date: Mon, 11 Sep 2006 08:36:02 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Re: Private extensions and relation to atom elements
In-reply-to: <20060911112712.GF17947@tartarus.org>
To: James Aylett <james@tartarus.org>
Cc: atom-syntax@imc.org
Message-id: <881B6ABB-AD8C-44DD-A592-80864A0C7F1B@sun.com>
MIME-version: 1.0
X-Mailer: Apple Mail (2.752.2)
Content-type: text/plain; format=flowed; charset=US-ASCII
Content-transfer-encoding: 7BIT
References: <20060911112712.GF17947@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>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 79899194edc4f33a41f49410777972f8



On Sep 11, 2006, at 4:27 AM, James Aylett wrote:

>
> We've run across a situation where we want to annotate an atom:icon
> with a title. Currently we're doing the following, as something that
> Feed Validator is happy with, but doesn't feel right:
>
> ----------------------------------------------------------------------
>   <atom:icon>uri:to/icon</atom:icon>
>   <myns:icon-title xml:lang='en' xmlns:myns='...'>My icon
>     title</myns:icon-title>

let's assume myns: is declared.  Then why not

<icon myns:buddha-nature="high" myns:sizzle="low">icon-uri<icon>

  -Tim




From owner-atom-syntax@mail.imc.org Mon Sep 11 11:54:13 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GMo6v-0002lx-Tk
	for atompub-archive@lists.ietf.org; Mon, 11 Sep 2006 11:54:13 -0400
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1GMo6t-0000NR-Gg
	for atompub-archive@lists.ietf.org; Mon, 11 Sep 2006 11:54:13 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k8BFa15V009678;
	Mon, 11 Sep 2006 08:36:01 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id k8BFa19v009677;
	Mon, 11 Sep 2006 08:36:01 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k8BFZxpX009670
	for <atom-syntax@imc.org>; Mon, 11 Sep 2006 08:36:00 -0700 (MST)
	(envelope-from Tim.Bray@Sun.COM)
Received: from fe-amer-02.sun.com ([192.18.108.176])
	by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k8BFZx7S003037
	for <atom-syntax@imc.org>; Mon, 11 Sep 2006 09:35:59 -0600 (MDT)
Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com
 (Sun Java System Messaging Server 6.2-4.02 (built Sep  9 2005))
 id <0J5F00D01PO01Y00@mail-amer.sun.com> (original mail from Tim.Bray@Sun.COM)
 for atom-syntax@imc.org; Mon, 11 Sep 2006 09:35:59 -0600 (MDT)
Received: from [192.168.1.15] ([216.113.204.64])
 by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep  9
 2005)) with ESMTPSA id <0J5F00MKPPYO9T83@mail-amer.sun.com>; Mon,
 11 Sep 2006 09:35:59 -0600 (MDT)
Date: Mon, 11 Sep 2006 08:36:48 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Re: Private extensions and relation to atom elements
In-reply-to: <20060911144553.GK17947@tartarus.org>
To: James Aylett <james@tartarus.org>
Cc: atom-syntax@imc.org
Message-id: <9106B7F8-7E5B-4C55-852B-7D0034BBFD8A@sun.com>
MIME-version: 1.0
X-Mailer: Apple Mail (2.752.2)
Content-type: text/plain; format=flowed; charset=US-ASCII
Content-transfer-encoding: 7BIT
References: <20060911112712.GF17947@tartarus.org> <4505724F.4000606@gmail.com>
 <20060911144553.GK17947@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>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed


On Sep 11, 2006, at 7:45 AM, James Aylett wrote:

> Feed Validator gets upset with extension attributes - is it wrong?

Be specific, please?  -Tim




From owner-atom-syntax@mail.imc.org Mon Sep 11 12:51:25 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GMp0H-0003s9-DM
	for atompub-archive@lists.ietf.org; Mon, 11 Sep 2006 12:51:25 -0400
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1GMp0F-0000JL-KR
	for atompub-archive@lists.ietf.org; Mon, 11 Sep 2006 12:51:24 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k8BGKthO016844;
	Mon, 11 Sep 2006 09:20:55 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id k8BGKtB9016843;
	Mon, 11 Sep 2006 09:20:55 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from ixion.tartarus.org (ixion.tartarus.org [82.211.108.121])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k8BGKsB8016836
	for <atom-syntax@imc.org>; Mon, 11 Sep 2006 09:20:55 -0700 (MST)
	(envelope-from james@ixion.tartarus.org)
Received: from james by ixion.tartarus.org with local (Exim 3.36 #1 (Debian))
	for atom-syntax@imc.org
	id 1GMoWk-00040M-00; Mon, 11 Sep 2006 17:20:54 +0100
Date: Mon, 11 Sep 2006 17:20:54 +0100
From: James Aylett <james@tartarus.org>
To: atom-syntax@imc.org
Subject: Re: Private extensions and relation to atom elements
Message-ID: <20060911162054.GM17947@tartarus.org>
Mail-Followup-To: James Aylett <james@tartarus.org>, atom-syntax@imc.org
References: <20060911112712.GF17947@tartarus.org> <881B6ABB-AD8C-44DD-A592-80864A0C7F1B@sun.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <881B6ABB-AD8C-44DD-A592-80864A0C7F1B@sun.com>
User-Agent: Mutt/1.5.9i
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d6b246023072368de71562c0ab503126


On Mon, Sep 11, 2006 at 08:36:02AM -0700, Tim Bray wrote:

> let's assume myns: is declared.  Then why not
> 
> <icon myns:buddha-nature="high" myns:sizzle="low">icon-uri<icon>

Apologies to all - this is what we tried first, but there must have
been a typo or something, because the feed validator started shouting
at us. I've just checked again, and all is well.

Cheers,
James

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




From training-tours@freenet.de Mon Sep 11 15:12:07 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GMrCR-0006bB-Ke
	for atompub-archive@megatron.ietf.org; Mon, 11 Sep 2006 15:12:07 -0400
Received: from [81.213.247.125] (helo=nati)
	by ietf-mx.ietf.org with smtp (Exim 4.43)
	id 1GMrCQ-00074q-2R
	for atompub-archive@megatron.ietf.org; Mon, 11 Sep 2006 15:12:07 -0400
Received: from nati[127.0.0.1] by nati[127.0.0.1]
  (SMTPD32); Mon, 11 Sep 2006 22:12:05 +0300
Organization: Training Tours.
Reply-To: info@trainingtours.org
Message-ID: <27ed8a00e75f62e0ce7dda14001568ab@freenet.de>
From: "Training Tours." <training-tours@freenet.de>
To: <atompub-archive@megatron.ietf.org>
Subject: Training Tours mit ist Spezialist fuer die Organisation von Sport Trainingslagern, Mannschaftsfahrten.
Date: Mon, 11 Sep 2006 22:09:47 +0300
MIME-Version: 1.0
Content-Type: text/plain;
	charset="windows-1251"
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 1.8 (+)
X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1

Training Tours ist Spezialist fur die Organisation von Trainingslagern, =
Mannschaftsfahrten sowie Sport- und Gruppenreisen in die Turkei. Nutzen =
Sie unsere Erfahrung  von Training Tours=2E

Fur die Wintersaison 2006/07 und 2007 haben wir folgende Programme fur Sie =
vorbereitet=2E
=20

-Leichtathletik Trainingslager in Antalya.=20

-Schwimmen Trainingslager in/bei Antalya.=20

-Veranstaltung von Tenniscamps, Golfcamps, Incentivereisen, z.B. Rallye =
Turkei

-Fussball Trainingslager in/bei Antalya und Belek-Kundu=20

-Hallensport z.B. Basketball=20

-Judocamp in Antalya

-Volleyballtraining und Beach- Volleyball -bei Alanya

-Allgemeine Vereins Reisen mit gute Konditionen.=20

=20

Kontaktieren Sie uns schon jetzt! Gerne sprechen wir mit Ihnen uber Ihre =
Vorstellungen und Wunsche bezuglich Ihres Trainingslagers und unterbreiten =
Ihnen ein individuelles Angebot,=20

Ihr Training Tours Team=2E

Das ist kein Spam, fur Remove senden Sie bitte eine Mail an =
training-tours@freenet.de






From owner-atom-syntax@mail.imc.org Mon Sep 11 19:09:34 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GMuuE-0008T1-Hs
	for atompub-archive@lists.ietf.org; Mon, 11 Sep 2006 19:09:34 -0400
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1GMupL-0000t7-1w
	for atompub-archive@lists.ietf.org; Mon, 11 Sep 2006 19:04:32 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k8BMbUoA068105;
	Mon, 11 Sep 2006 15:37:30 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id k8BMbU5O068104;
	Mon, 11 Sep 2006 15:37:30 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.174])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k8BMbTbn068095
	for <atom-syntax@imc.org>; Mon, 11 Sep 2006 15:37:29 -0700 (MST)
	(envelope-from algermissen1971@mac.com)
Received: from mac.com (smtpin03-en2 [10.13.10.148])
	by smtpout.mac.com (Xserve/8.12.11/smtpout04/MantshX 4.0) with ESMTP id k8BMbSrV027087
	for <atom-syntax@imc.org>; Mon, 11 Sep 2006 15:37:29 -0700 (PDT)
Received: from [80.171.131.165] (d131165.adsl.hansenet.de [80.171.131.165])
	(authenticated bits=0)
	by mac.com (Xserve/smtpin03/MantshX 4.0) with ESMTP id k8BMbOle014447
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO)
	for <atom-syntax@imc.org>; Mon, 11 Sep 2006 15:37:27 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v752.2)
Content-Transfer-Encoding: 7bit
Message-Id: <A8D3D850-EC8C-41B5-A7F2-C50FBFCC6841@mac.com>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
To: atom-syntax@imc.org
From: Jan Algermissen <algermissen1971@mac.com>
Subject: versioning extension?
Date: Tue, 12 Sep 2006 00:40:33 +0200
X-Mailer: Apple Mail (2.752.2)
X-Brightmail-Tracker: AAAAAQAAA+k=
X-Language-Identified: TRUE
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
X-Spam-Score: 1.5 (+)
X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c


Hi,

is anybody working on (or planning to work on) a versioning extension  
for Atom? I am about to use Atom in two (considerably different)  
projects that require versioning and would be happy to join forces  
and contribute real (enterprise-)world use cases. (Note: not  
'enterprisey' use cases :-)


Jan

  
  




From owner-atom-syntax@mail.imc.org Mon Sep 11 19:47:48 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GMvVE-00070Q-Ho
	for atompub-archive@lists.ietf.org; Mon, 11 Sep 2006 19:47:48 -0400
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1GMvVD-000533-48
	for atompub-archive@lists.ietf.org; Mon, 11 Sep 2006 19:47:48 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k8BNNPMw074216;
	Mon, 11 Sep 2006 16:23:25 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id k8BNNPh8074215;
	Mon, 11 Sep 2006 16:23:25 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k8BNNObr074209
	for <atom-syntax@imc.org>; Mon, 11 Sep 2006 16:23:24 -0700 (MST)
	(envelope-from Tim.Bray@Sun.COM)
Received: from fe-amer-02.sun.com ([192.18.108.176])
	by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k8BNNNtY002127
	for <atom-syntax@imc.org>; Mon, 11 Sep 2006 17:23:24 -0600 (MDT)
Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com
 (Sun Java System Messaging Server 6.2-4.02 (built Sep  9 2005))
 id <0J5G00I01B0RO500@mail-amer.sun.com> (original mail from Tim.Bray@Sun.COM)
 for atom-syntax@imc.org; Mon, 11 Sep 2006 17:23:23 -0600 (MDT)
Received: from [192.168.1.15] ([216.113.204.64])
 by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep  9
 2005)) with ESMTPSA id <0J5G00MA2BMU9TQ3@mail-amer.sun.com>; Mon,
 11 Sep 2006 17:23:23 -0600 (MDT)
Date: Mon, 11 Sep 2006 16:23:59 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Re: versioning extension?
In-reply-to: <A8D3D850-EC8C-41B5-A7F2-C50FBFCC6841@mac.com>
To: Jan Algermissen <algermissen1971@mac.com>
Cc: atom-syntax@imc.org
Message-id: <EE8D431D-A3EE-44EE-A534-C0ACE860069E@sun.com>
MIME-version: 1.0
X-Mailer: Apple Mail (2.752.2)
Content-type: text/plain; format=flowed; delsp=yes; charset=US-ASCII
Content-transfer-encoding: 7BIT
References: <A8D3D850-EC8C-41B5-A7F2-C50FBFCC6841@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>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199


On Sep 11, 2006, at 3:40 PM, Jan Algermissen wrote:

> is anybody working on (or planning to work on) a versioning  
> extension for Atom? I am about to use Atom in two (considerably  
> different) projects that require versioning and would be happy to  
> join forces and contribute real (enterprise-)world use cases.  
> (Note: not 'enterprisey' use cases :-)

Eeeeeeeeeeeeeeeeeeeeeeek!  Flee for your lives!  *runs for the  
nearest exit*  -Tim




From owner-atom-syntax@mail.imc.org Mon Sep 11 19:53:47 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GMvb1-0001E4-Kz
	for atompub-archive@lists.ietf.org; Mon, 11 Sep 2006 19:53:47 -0400
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1GMvaz-0005mZ-8Y
	for atompub-archive@lists.ietf.org; Mon, 11 Sep 2006 19:53:47 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k8BNZxA9076092;
	Mon, 11 Sep 2006 16:35:59 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id k8BNZxhm076091;
	Mon, 11 Sep 2006 16:35:59 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.174])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k8BNZwZ9076085
	for <atom-syntax@imc.org>; Mon, 11 Sep 2006 16:35:58 -0700 (MST)
	(envelope-from algermissen1971@mac.com)
Received: from mac.com (smtpin07-en2 [10.13.10.152])
	by smtpout.mac.com (Xserve/8.12.11/smtpout04/MantshX 4.0) with ESMTP id k8BNZvFv015795;
	Mon, 11 Sep 2006 16:35:58 -0700 (PDT)
Received: from [80.171.131.165] (d131165.adsl.hansenet.de [80.171.131.165])
	(authenticated bits=0)
	by mac.com (Xserve/smtpin07/MantshX 4.0) with ESMTP id k8BNZqH3024336
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO);
	Mon, 11 Sep 2006 16:35:56 -0700 (PDT)
In-Reply-To: <EE8D431D-A3EE-44EE-A534-C0ACE860069E@sun.com>
References: <A8D3D850-EC8C-41B5-A7F2-C50FBFCC6841@mac.com> <EE8D431D-A3EE-44EE-A534-C0ACE860069E@sun.com>
Mime-Version: 1.0 (Apple Message framework v752.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <A69CD4B1-C7FB-4F50-A46D-CD848843A050@mac.com>
Cc: atom-syntax@imc.org
Content-Transfer-Encoding: 7bit
From: Jan Algermissen <algermissen1971@mac.com>
Subject: Re: versioning extension?
Date: Tue, 12 Sep 2006 01:39:01 +0200
To: Tim Bray <Tim.Bray@Sun.COM>
X-Mailer: Apple Mail (2.752.2)
X-Brightmail-Tracker: AAAAAQAAA+k=
X-Language-Identified: TRUE
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
X-Spam-Score: 1.5 (+)
X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a



On 12.09.2006, at 01:23, Tim Bray wrote:

> On Sep 11, 2006, at 3:40 PM, Jan Algermissen wrote:
>
>> is anybody working on (or planning to work on) a versioning  
>> extension for Atom? I am about to use Atom in two (considerably  
>> different) projects that require versioning and would be happy to  
>> join forces and contribute real (enterprise-)world use cases.  
>> (Note: not 'enterprisey' use cases :-)
>
> Eeeeeeeeeeeeeeeeeeeeeeek!  Flee for your lives!  *runs for the  
> nearest exit*  -Tim

Umm...am I missing  something? Is it that bad?

What I am basically aiming at is a common means to relate entries to  
each other to indicate one is a version of the other or to link from  
an entry to a feed that consists of versions of that entry,

If I am not completely wrong, versioning is definitely an issue if  
you want to employ Atom in beyond-blogging contexts. Most people that  
deal with collections of items are definitely interested in keeping  
track of the former versions of the items.

What is so bad about it?

Jan




From owner-atom-syntax@mail.imc.org Mon Sep 11 20:36:55 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GMwGl-0002M2-Pj
	for atompub-archive@lists.ietf.org; Mon, 11 Sep 2006 20:36:55 -0400
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1GMwGk-0003x9-Ce
	for atompub-archive@lists.ietf.org; Mon, 11 Sep 2006 20:36:55 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k8C0ICTD081666;
	Mon, 11 Sep 2006 17:18:12 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id k8C0ICsg081665;
	Mon, 11 Sep 2006 17:18:12 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from homer.w3.org (homer.w3.org [128.30.52.30])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k8C0IBST081659
	for <atom-syntax@imc.org>; Mon, 11 Sep 2006 17:18:12 -0700 (MST)
	(envelope-from karl@w3.org)
Received: from [127.0.0.1] (homer.w3.org [128.30.52.30])
	by homer.w3.org (Postfix) with ESMTP id 9A3C14EF0F;
	Mon, 11 Sep 2006 20:18:09 -0400 (EDT)
In-Reply-To: <A69CD4B1-C7FB-4F50-A46D-CD848843A050@mac.com>
References: <A8D3D850-EC8C-41B5-A7F2-C50FBFCC6841@mac.com> <EE8D431D-A3EE-44EE-A534-C0ACE860069E@sun.com> <A69CD4B1-C7FB-4F50-A46D-CD848843A050@mac.com>
Mime-Version: 1.0 (Apple Message framework v752.2)
Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed
Message-Id: <1AC0B43D-7E77-4BBC-A673-7C64CCC0880F@w3.org>
Cc: Tim Bray <Tim.Bray@Sun.COM>, atom-syntax@imc.org
From: Karl Dubost <karl@w3.org>
Subject: Re: versioning extension?
Date: Tue, 12 Sep 2006 09:17:18 +0900
To: Jan Algermissen <algermissen1971@mac.com>
X-Mailer: Apple Mail (2.752.2)
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k8C0ICST081660
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id k8C0ICTD081666
X-Spam-Score: 0.0 (/)
X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024



Le 12 sept. 06 =E0 08:39, Jan Algermissen a =E9crit :
> Umm...am I missing  something? Is it that bad?
>
> What I am basically aiming at is a common means to relate entries =20
> to each other to indicate one is a version of the other or to link =20
> from an entry to a feed that consists of versions of that entry,
>
> If I am not completely wrong, versioning is definitely an issue if =20
> you want to employ Atom in beyond-blogging contexts. Most people =20
> that deal with collections of items are definitely interested in =20
> keeping track of the former versions of the items.

Are you talking about threading?

Why not putting it outside of Atom and use the power of links for =20
threading.
Similar discussion but for comments happened on microformats ML.


So IMHO, it is slightly off-topic, in the sense you could achieve it =20
by an application built on top of Atom without touching Atom
AND Tim Bray could come back in the room :p


 From the microformats ML

Le 12 sept. 06 =E0 08:35, Karl Dubost a =E9crit :
> Hi Steph,
>
> Le 12 sept. 06 =E0 07:17, Stephanie Booth (bunny) a =E9crit :
>> A while back somebody showed me a blog marked up with hatom. That
>> person used hatom on the comments too (on the single post page) --
>> that meant two hfeeds: one containing only the post, and another one
>> with the comments.
>>
>> Does this way of using hatom on comments make sense to you? I noticed
>> that neither K2 nor Sandbox wordpress themes do this.
>
> Completely logical.
>
> Each individual comment is nothing more than a weblog post.
> The only technical difference is that it is not made on another =20
> weblog, but directly on the weblog of the person.
>
> Each individual comment is structured like a weblog post.
> It has  (required)
> 	- an id, the URI of the comment
> 	- a title, often the same than the original weblog post, sometimes =20
> a different (see SPIP)
> 	- a date when it has been done (updated)
> It has (recommended)
> 	- often an author
> 	- content (core text of the comment)
> 	- link (the URI of the Weblog original post we are commenting on)
>
> It just miss a summary, but that is not mandatory in Atom either.
>
> IMHO, it should be an individual hatom entry for each comment, The =20
> way everything is aggregated and organized has a full feed is =20
> another debate. The date and link should help to create a pseudo =20
> thread.
> It could be a full thread like in SPIP when the commenter has the =20
> possibility to reply to a specific comment in this case the link =20
> becomes the URI of the specific comment.
>





--=20
Karl Dubost - http://www.w3.org/People/karl/
W3C Conformance Manager, QA Activity Lead
   QA Weblog - http://www.w3.org/QA/
      *** Be Strict To Be Cool ***






From owner-atom-syntax@mail.imc.org Mon Sep 11 20:39:07 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GMwIt-0002kI-SH
	for atompub-archive@lists.ietf.org; Mon, 11 Sep 2006 20:39:07 -0400
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1GMwIp-0004Em-C2
	for atompub-archive@lists.ietf.org; Mon, 11 Sep 2006 20:39:07 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k8C0K34g081814;
	Mon, 11 Sep 2006 17:20:03 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id k8C0K3jB081813;
	Mon, 11 Sep 2006 17:20:03 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k8C0K1MD081807
	for <atom-syntax@imc.org>; Mon, 11 Sep 2006 17:20:02 -0700 (MST)
	(envelope-from Tim.Bray@Sun.COM)
Received: from fe-amer-03.sun.com ([192.18.108.177])
	by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k8C0K1MB019653
	for <atom-syntax@imc.org>; Mon, 11 Sep 2006 18:20:01 -0600 (MDT)
Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com
 (Sun Java System Messaging Server 6.2-4.02 (built Sep  9 2005))
 id <0J5G00G01D8TZ800@mail-amer.sun.com> (original mail from Tim.Bray@Sun.COM)
 for atom-syntax@imc.org; Mon, 11 Sep 2006 18:20:01 -0600 (MDT)
Received: from [192.168.1.15] ([216.113.204.64])
 by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep  9
 2005)) with ESMTPSA id <0J5G00BTLE9AAP81@mail-amer.sun.com>; Mon,
 11 Sep 2006 18:19:58 -0600 (MDT)
Date: Mon, 11 Sep 2006 17:20:48 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Re: versioning extension?
In-reply-to: <A69CD4B1-C7FB-4F50-A46D-CD848843A050@mac.com>
To: Jan Algermissen <algermissen1971@mac.com>
Cc: atom-syntax@imc.org
Message-id: <7EDB0171-9385-4C37-AD90-D31E864DD761@Sun.COM>
MIME-version: 1.0
X-Mailer: Apple Mail (2.752.2)
Content-type: text/plain; format=flowed; delsp=yes; charset=ISO-8859-1
References: <A8D3D850-EC8C-41B5-A7F2-C50FBFCC6841@mac.com>
 <EE8D431D-A3EE-44EE-A534-C0ACE860069E@sun.com>
 <A69CD4B1-C7FB-4F50-A46D-CD848843A050@mac.com>
X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by balder-227.proper.com id k8C0K2MD081808
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id k8C0K34g081814
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906


On Sep 11, 2006, at 4:39 PM, Jan Algermissen wrote:

> If I am not completely wrong, versioning is definitely an issue if =20
> you want to employ Atom in beyond-blogging contexts. Most people =20
> that deal with collections of items are definitely interested in =20
> keeping track of the former versions of the items.

Versioning is an issue in almost *every* application.

> What is so bad about it?

In my experience, the semantics of "versioning" are so tightly bound =20
to particular applications that it's really hard to find common =20
threads.  You saw that happen here when we were arguing about =20
atom:updated, Asbj=F8rn had a particular vision of versions that seemed =20
obvious to him and unreasonable to others.  When a textbook publisher =20
and a medical-instrument embedded-software maker and a wiki =20
implementor use the word "version", I guarantee you they mean =20
entirely different and wildly incompatible things.

Good luck; you'll need it. -Tim




From owner-atom-syntax@mail.imc.org Tue Sep 12 05:35:32 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GN4g0-0007h7-8G
	for atompub-archive@lists.ietf.org; Tue, 12 Sep 2006 05:35:32 -0400
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1GN4fr-0002Vh-Q0
	for atompub-archive@lists.ietf.org; Tue, 12 Sep 2006 05:35:32 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k8C8p3RH063869;
	Tue, 12 Sep 2006 01:51:03 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id k8C8p32N063868;
	Tue, 12 Sep 2006 01:51:03 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.46])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k8C8p2lL063862
	for <atom-syntax@imc.org>; Tue, 12 Sep 2006 01:51:02 -0700 (MST)
	(envelope-from algermissen1971@mac.com)
Received: from mac.com (webmail26-en1 [10.13.8.88])
	by smtpout.mac.com (Xserve/8.12.11/smtpout10/MantshX 4.0) with ESMTP id k8C8p1HS017022;
	Tue, 12 Sep 2006 01:51:01 -0700 (PDT)
Received: from webmail26 (localhost [127.0.0.1])
	by mac.com (Xserve/webmail26/MantshX 4.0) with ESMTP id k8C8p0V2006174;
	Tue, 12 Sep 2006 01:51:00 -0700 (PDT)
Received: from [193.7.250.35] by webmail.mac.com with HTTP; Tue, 12 Sep 2006 10:51:00 +0200
Message-ID: <1865781.1158051060500.JavaMail.algermissen1971@mac.com>
Date: Tue, 12 Sep 2006 10:51:00 +0200
From: Jan Algermissen <algermissen1971@mac.com>
To: karl@w3.org
Subject: Re: versioning extension?
Cc: Tim.Bray@Sun.COM, atom-syntax@imc.org
in-reply-to: <1AC0B43D-7E77-4BBC-A673-7C64CCC0880F@w3.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
references: <A8D3D850-EC8C-41B5-A7F2-C50FBFCC6841@mac.com>
 <EE8D431D-A3EE-44EE-A534-C0ACE860069E@sun.com>
 <A69CD4B1-C7FB-4F50-A46D-CD848843A050@mac.com> <1AC0B43D-7E77-4BBC-A673-7C64CCC0880F@w3.org>
X-Originating-IP: 193.7.250.35/instID=389
X-Brightmail-Tracker: AAAAAQAAA+k=
X-Language-Identified: TRUE
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k8C8p2lL063863
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id k8C8p3RH063869
X-Spam-Score: 0.5 (/)
X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196


 Karl,

On Tuesday, September 12, 2006, at 02:37AM, Karl Dubost <karl@w3.org> wro=
te:

>
>
>Le 12 sept. 06 =E0 08:39, Jan Algermissen a =E9crit :
>> Umm...am I missing  something? Is it that bad?
>>
>> What I am basically aiming at is a common means to relate entries =20
>> to each other to indicate one is a version of the other or to link =20
>> from an entry to a feed that consists of versions of that entry,
>>
>> If I am not completely wrong, versioning is definitely an issue if =20
>> you want to employ Atom in beyond-blogging contexts. Most people =20
>> that deal with collections of items are definitely interested in =20
>> keeping track of the former versions of the items.
>
>Are you talking about threading?

I did consider re-using threading, but thought the semantics are really t=
o different. OTH, I did not take an in depth look, so maybe there is an e=
ntry-to-entry relationship that can be re-used.

>
>Why not putting it outside of Atom and use the power of links for =20
>threading.

I really did not have a modification to atom in mind (maybe I used the na=
me 'extension' improperly). I was only looking for a relatively standardi=
zed way to link items to derived items or vice versa.

BTW: Can the cotent of an atom enry contain or link to an atom feed docum=
ent?

Thanks.

Jan


>Similar discussion but for comments happened on microformats ML.
>
>
>So IMHO, it is slightly off-topic, in the sense you could achieve it =20
>by an application built on top of Atom without touching Atom
>AND Tim Bray could come back in the room :p
>
>
> From the microformats ML
>
>Le 12 sept. 06 =E0 08:35, Karl Dubost a =E9crit :
>> Hi Steph,
>>
>> Le 12 sept. 06 =E0 07:17, Stephanie Booth (bunny) a =E9crit :
>>> A while back somebody showed me a blog marked up with hatom. That
>>> person used hatom on the comments too (on the single post page) --
>>> that meant two hfeeds: one containing only the post, and another one
>>> with the comments.
>>>
>>> Does this way of using hatom on comments make sense to you? I noticed
>>> that neither K2 nor Sandbox wordpress themes do this.
>>
>> Completely logical.
>>
>> Each individual comment is nothing more than a weblog post.
>> The only technical difference is that it is not made on another =20
>> weblog, but directly on the weblog of the person.
>>
>> Each individual comment is structured like a weblog post.
>> It has  (required)
>> 	- an id, the URI of the comment
>> 	- a title, often the same than the original weblog post, sometimes =20
>> a different (see SPIP)
>> 	- a date when it has been done (updated)
>> It has (recommended)
>> 	- often an author
>> 	- content (core text of the comment)
>> 	- link (the URI of the Weblog original post we are commenting on)
>>
>> It just miss a summary, but that is not mandatory in Atom either.
>>
>> IMHO, it should be an individual hatom entry for each comment, The =20
>> way everything is aggregated and organized has a full feed is =20
>> another debate. The date and link should help to create a pseudo =20
>> thread.
>> It could be a full thread like in SPIP when the commenter has the =20
>> possibility to reply to a specific comment in this case the link =20
>> becomes the URI of the specific comment.
>>
>
>
>
>
>
>--=20
>Karl Dubost - http://www.w3.org/People/karl/
>W3C Conformance Manager, QA Activity Lead
>   QA Weblog - http://www.w3.org/QA/
>      *** Be Strict To Be Cool ***
>
>
>
>
>


------------------------------------------------------------
Jan Algermissen                                               http://jalg=
ermissen.com
Software Architect                                            http://www.=
tugboat.de





From owner-atom-syntax@mail.imc.org Tue Sep 12 06:15:46 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GN5Iw-0004t9-4K
	for atompub-archive@lists.ietf.org; Tue, 12 Sep 2006 06:15:46 -0400
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1GN5Ir-0007Gw-O3
	for atompub-archive@lists.ietf.org; Tue, 12 Sep 2006 06:15:46 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k8C9q9Tr072839;
	Tue, 12 Sep 2006 02:52:09 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id k8C9q9mh072838;
	Tue, 12 Sep 2006 02:52:09 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mout1.freenet.de (mout1.freenet.de [194.97.50.132])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k8C9q8xB072824
	for <atom-syntax@imc.org>; Tue, 12 Sep 2006 02:52:08 -0700 (MST)
	(envelope-from sewe@rbg.informatik.tu-darmstadt.de)
Received: from [194.97.55.148] (helo=mx5.freenet.de)
	by mout1.freenet.de with esmtpa (Exim 4.62)
	(envelope-from <sewe@rbg.informatik.tu-darmstadt.de>)
	id 1GN4w0-00082a-TR; Tue, 12 Sep 2006 11:52:04 +0200
Received: from ultra15.rbg.informatik.tu-darmstadt.de ([130.83.160.105])
	by mx5.freenet.de with esmtpsa (ID sewe2004@freenet.de) (TLSv1:AES256-SHA:256) (Exim 4.62 #12)
	id 1GN4w0-0001uQ-Or; Tue, 12 Sep 2006 11:52:04 +0200
Message-ID: <45068342.3010904@rbg.informatik.tu-darmstadt.de>
Date: Tue, 12 Sep 2006 11:52:02 +0200
From: Andreas Sewe <sewe@rbg.informatik.tu-darmstadt.de>
Organization: Fachbereich Informatik, TU Darmstadt
User-Agent: Mail/News 1.5.0.5 (X11/20060727)
MIME-Version: 1.0
To: Jan Algermissen <algermissen1971@mac.com>
CC: atom-syntax@imc.org
Subject: Re: versioning extension?
References: <A8D3D850-EC8C-41B5-A7F2-C50FBFCC6841@mac.com>
In-Reply-To: <A8D3D850-EC8C-41B5-A7F2-C50FBFCC6841@mac.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>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 79899194edc4f33a41f49410777972f8


Jan Algermissen wrote:
> is anybody working on (or planning to work on) a versioning extension 
> for Atom? I am about to use Atom in two (considerably different) 
> projects that require versioning and would be happy to join forces and 
> contribute real (enterprise-)world use cases. (Note: not 'enterprisey' 
> use cases :-)

Maybe dcterms:isVersionOf and dcterms:hasVersion fit your bill [1]. 
Granted, their definition is rather loose (as most of Dublincore's 
definition are -- by design), but that only means that those terms might 
work in both of your use cases. If so, using an established metadata 
vocabulary like Dublincore is definitely worth considering.

I hope that helps,

Andreas Sewe

[1] <http://dublincore.org/documents/dcmi-terms/#H3>




From owner-atom-syntax@mail.imc.org Tue Sep 12 06:16:20 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GN5JU-0004u5-O3
	for atompub-archive@lists.ietf.org; Tue, 12 Sep 2006 06:16:20 -0400
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1GN5JT-0007OR-B6
	for atompub-archive@lists.ietf.org; Tue, 12 Sep 2006 06:16:20 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k8C9j2Ik071714;
	Tue, 12 Sep 2006 02:45:02 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id k8C9j2mt071713;
	Tue, 12 Sep 2006 02:45:02 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.187])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k8C9j08t071697
	for <atom-syntax@imc.org>; Tue, 12 Sep 2006 02:45:01 -0700 (MST)
	(envelope-from t.broyer@gmail.com)
Received: by nf-out-0910.google.com with SMTP id o60so1426534nfa
        for <atom-syntax@imc.org>; Tue, 12 Sep 2006 02:44:59 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=sC1GwMy7zp4rm6O6Arfz9DTJ/jm04aD1UlH6YhjnGQq7iWjr6WRg6dQuR1LkrmuKDascx/mKbVOnwVhQdhR+TUL5Mb0eBW7/6UYa4Xs4Rk1WQoV4d8j8n9oKe+hUa0RRmN22A7RBOAcMRxswXcnriN1hOwm7DFZOO3g05BjjLo4=
Received: by 10.49.8.4 with SMTP id l4mr9335336nfi;
        Tue, 12 Sep 2006 02:44:59 -0700 (PDT)
Received: by 10.49.29.19 with HTTP; Tue, 12 Sep 2006 02:44:58 -0700 (PDT)
Message-ID: <a9699fd20609120244n76ed0834p9183435f747d2fe9@mail.gmail.com>
Date: Tue, 12 Sep 2006 11:44:58 +0200
From: "Thomas Broyer" <t.broyer@gmail.com>
To: Atom-Syntax <atom-syntax@imc.org>
Subject: Re: versioning extension?
In-Reply-To: <A8D3D850-EC8C-41B5-A7F2-C50FBFCC6841@mac.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <A8D3D850-EC8C-41B5-A7F2-C50FBFCC6841@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>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2


2006/9/12, Jan Algermissen:
> is anybody working on (or planning to work on) a versioning extension
> for Atom? I am about to use Atom in two (considerably different)
> projects that require versioning and would be happy to join forces
> and contribute real (enterprise-)world use cases. (Note: not
> 'enterprisey' use cases :-)

Have you looked at this?
http://tools.ietf.org/wg/atompub/draft-snell-atompub-revision-00.txt

-- 
Thomas Broyer