Re: Atom Content Negotiation (follow-up)

Peter Krantz <peter.krantz@gmail.com> Sun, 01 May 2011 08:38 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 51548E065F for <ietfarch-atompub-archive@ietfa.amsl.com>; Sun, 1 May 2011 01:38:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 0GUNUjhBjmLH for <ietfarch-atompub-archive@ietfa.amsl.com>; Sun, 1 May 2011 01:38:37 -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 75A56E0651 for <atompub-archive@ietf.org>; Sun, 1 May 2011 01:38:36 -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 p418Wx4f097923 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 1 May 2011 01:33:00 -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 p418Wx4p097922; Sun, 1 May 2011 01:32:59 -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 mail-vx0-f171.google.com (mail-vx0-f171.google.com [209.85.220.171]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p418Ww2T097917 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL) for <atom-syntax@imc.org>; Sun, 1 May 2011 01:32:59 -0700 (MST) (envelope-from peter.krantz@gmail.com)
Received: by vxc40 with SMTP id 40so5843231vxc.16 for <atom-syntax@imc.org>; Sun, 01 May 2011 01:32:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=RQZs3ro7YKXnjamO10VraU8IJSmxVy6SN8ND1xgdYSY=; b=KdgnPHWZoP9b/z4bTOk8fibCnYNICo+M0DkZv1YHOdT7Oi6yt6oLTPANI7FpqSWs10 drlbvjzY+BRYLbSUL7+TqS7amirBniWD/Y7YTEncAYNXd1DXKfUJWrs/P4t8e1uMhnVc dzxbHwTTW0NLG4805F8tba6j1rqznTl1WIS7c=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=MJ5fRdwpospAAxYLGVf20Y8n79JKoJ0SvcTwEzN+G5bFqsxD/Xth/Q6yOUjimWv167 wyLVMU9n143D5bd99Ht77w06ZU7mImI9eHlEdl7FiCfko2mTHtBuUQ9KCO/k0aToB8XI Om+lEvARC0+uy3E8uJQF0uWZfaxQFnqVXLak4=
MIME-Version: 1.0
Received: by 10.52.175.195 with SMTP id cc3mr4500445vdc.242.1304238777435; Sun, 01 May 2011 01:32:57 -0700 (PDT)
Received: by 10.52.168.161 with HTTP; Sun, 1 May 2011 01:32:57 -0700 (PDT)
In-Reply-To: <4DBC60F4.7000402@berkeley.edu>
References: <4DBC60F4.7000402@berkeley.edu>
Date: Sun, 01 May 2011 10:32:57 +0200
Message-ID: <BANLkTik-dPFJKzWDBSvvTywVrKZ-hQCRMQ@mail.gmail.com>
Subject: Re: Atom Content Negotiation (follow-up)
From: Peter Krantz <peter.krantz@gmail.com>
To: Atom-Syntax Syntax <atom-syntax@imc.org>
Content-Type: text/plain; charset="ISO-8859-1"
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>

On Sat, Apr 30, 2011 at 21:20, Erik Wilde <dret@berkeley.edu> wrote:
>
> the problem is that this link relation needs a parameter (specifying what
> the media type of the linked feed/entry/content is) and maybe some title
> text.

Forgive me if I have misunderstood the use case scenarios here, but:

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?

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 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.

Regards,

Peter Krantz