Re: Atom Content Negotiation (follow-up)

Erik Wilde <dret@berkeley.edu> Sun, 01 May 2011 17:26 UTC

Return-Path: <owner-atom-syntax@mail.imc.org>
X-Original-To: ietfarch-atompub-archive@ietfa.amsl.com
Delivered-To: ietfarch-atompub-archive@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 007D5E06F4 for <ietfarch-atompub-archive@ietfa.amsl.com>; Sun, 1 May 2011 10:26:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EnVS+RADfPsN for <ietfarch-atompub-archive@ietfa.amsl.com>; Sun, 1 May 2011 10:26:30 -0700 (PDT)
Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2001:4870:a30c:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id D63F7E06A5 for <atompub-archive@ietf.org>; Sun, 1 May 2011 10:26:29 -0700 (PDT)
Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p41HLkfP013477 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 1 May 2011 10:21:46 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id p41HLk98013476; Sun, 1 May 2011 10:21:46 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from cm03fe.IST.Berkeley.EDU (cm03fe.IST.Berkeley.EDU [169.229.218.144]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p41HLiAd013471 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <atom-syntax@imc.org>; Sun, 1 May 2011 10:21:45 -0700 (MST) (envelope-from dret@berkeley.edu)
Received: from 173-228-119-48.dsl.dynamic.sonic.net ([173.228.119.48] helo=[192.168.1.13]) by cm03fe.ist.berkeley.edu with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (auth plain:dret@berkeley.edu) (envelope-from <dret@berkeley.edu>) id 1QGaL0-0002gm-CC; Sun, 01 May 2011 10:21:43 -0700
References: <4DBC60F4.7000402@berkeley.edu> <BANLkTik-dPFJKzWDBSvvTywVrKZ-hQCRMQ@mail.gmail.com>
In-Reply-To: <BANLkTik-dPFJKzWDBSvvTywVrKZ-hQCRMQ@mail.gmail.com>
Mime-Version: 1.0 (iPad Mail 8H7)
Content-Type: text/plain; charset="us-ascii"
Message-Id: <D86D1E29-7A5F-4486-8BBC-6D9C68212E9B@berkeley.edu>
Cc: Atom-Syntax Syntax <atom-syntax@imc.org>
X-Mailer: iPad Mail (8H7)
From: Erik Wilde <dret@berkeley.edu>
Subject: Re: Atom Content Negotiation (follow-up)
Date: Sun, 01 May 2011 10:21:40 -0700
To: Peter Krantz <peter.krantz@gmail.com>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by hoffman.proper.com id p41HLkAc013472
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>

hello peter.

thanks for your comment!

> It looks like you will be duplicating the value of the link relation
> in the link element type attribute for each entry in the target feed?
> How would you handle discrepancies if the marked feed had entries with
> a different value?

i think i wasn't clear enough. my proposal would only be for feed/link elements, not for feed/entry/link elements. the idea is to point to a variant of the whole feed, not to individual entries. it should be a link y can follow when you want to consume a different feed, one that has different "primary" content. and each "feed variant" would be a regular feed and thus be free to link to entry alternate versions. the label i am thinking of would indicate something you might call the feed's "primary content type".

> If there are multiple feeds for a given set of resources, how can I
> trust I am getting the same updates in each of the feeds?

i don't think you can trust the publisher a 100%, but it's a good thing to point out, and the link relation should probably say that "publishers SHOULD try to expose updates across feed variants in a consistent manner", or something along these lines.

> I see a lot of benefit in having one feed with multiple link elements.
> If I'm only interested in the RDF entries I am still doing the same
> number of requests (one for the feed and then one for each entry I am
> interested in)?  And I can trust I get all updates at the same time.

you're right that there is an issue with trust and consistency, which is probably very hard to formalize or standardize. on the other hand, if you follow a feed that embeds non-RDF (and limks to RDF alternates) and you got 10 new entries when reading the feed, you need a total of 11 GETs to retrieve the data you're interested in. if there was an feed embedding RDF, it's just one GET and you're done. for resource-constrained scenarios such as mobile or embedded systems, and in particular for push support, this is a very significant difference.

thanks and cheers,

dret.
>