Reading the example from
http://ietfreport.isoc.org/idref/draft-snell-atompub-feed-license/
[[[
3. The 'license' link relation
An Atom link element with a 'rel' attribute value of 'license' is
used to associate a copyright license with an Atom Feed or Entry.
Atom entry, feed a
Le 06-06-08 à 19:40, A. Pagaltzis a écrit :
* Karl Dubost <[EMAIL PROTECTED]> [2006-06-08 04:30]:
Which will not remove abuse :)
Well, will anything short of not publishing your content?
I think the point of such an effort is to make life easier for
third parties who want to respect your wi
A. Pagaltzis wrote on 6/8/2006, 3:40 AM:
>
> * Karl Dubost <[EMAIL PROTECTED]> [2006-06-08 04:30]:
> > Which will not remove abuse :)
>
> Well, will anything short of not publishing your content?
>
> I think the point of such an effort is to make life easier for
> third parties who want t
Thomas Broyer wrote:
Could you read my recent mails in this thread and confirm that it's the
case?
I'm sorry, but I can no longer participate in this discussion. I hope
everything works out ok.
Regards
James
On 2006/06/07, at 11:40 PM, Thomas Broyer wrote:
My main concern is that RFC3229 w/ feeds is being deployed more and
more widely and is still not even an I-D (or I missed something).
I have that concern as well.
I am also concerned that RFC3229 is an extension of HTTP, but some
implemente
Very well stated, Aristotle!On 6/8/06, A. Pagaltzis <[EMAIL PROTECTED]> wrote:
* Karl Dubost <[EMAIL PROTECTED]> [2006-06-08 04:30]:> Which will not remove abuse :)Well, will anything short of not publishing your content?I think the point of such an effort is to make life easier for
third parties w
Elliotte Harold schrieb:
James M Snell wrote:
That's not quite accurate. Two entries with the same atom:id may appear
within the same atom:feed only if they have different atom:updated
elements. The spec is silent on whether or not two entries existing in
*separate documents* may have ident
On 8 Jun 2006, at 14:44, Elliotte Harold wrote:
James M Snell wrote:
That's not quite accurate. Two entries with the same atom:id may
appear
within the same atom:feed only if they have different atom:updated
elements. The spec is silent on whether or not two entries
existing in
*separ
James M Snell wrote:
That's not quite accurate. Two entries with the same atom:id may appear
within the same atom:feed only if they have different atom:updated
elements. The spec is silent on whether or not two entries existing in
*separate documents* may have identical atom:id and atom:updat
* Karl Dubost <[EMAIL PROTECTED]> [2006-06-08 04:30]:
> Which will not remove abuse :)
Well, will anything short of not publishing your content?
I think the point of such an effort is to make life easier for
third parties who want to respect your wishes, not to make it
harder for third parties w
2006/6/8, James Holderness <[EMAIL PROTECTED]>:
Thomas Broyer wrote:
> That means you need to keep entry revisions as well, so that if an
> entry is updated while a client is navigating the paged result set, it
> is sent the "old" revision (corresponding to the "date" parameter).
Why? If an en
Thomas Broyer wrote:
What you described is RFC3229 w/ feeds [1], but you failed to include
the new request and response headers and the specific status code,
which are necessary because you're changing the behaviour of
If-None-Match and 304 (Not Modified) as defined in HTTP/1.1.
Yep. Sorry, fo
12 matches
Mail list logo
