Re: deprecate icon and logo elements?

James Snell <jasnell@gmail.com> Wed, 13 October 2010 18:02 UTC

Return-Path: <owner-atom-syntax@mail.imc.org>
X-Original-To: ietfarch-atompub-archive@core3.amsl.com
Delivered-To: ietfarch-atompub-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 17DFC3A6AC2 for <ietfarch-atompub-archive@core3.amsl.com>; Wed, 13 Oct 2010 11:02:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.999
X-Spam-Level:
X-Spam-Status: No, score=0.999 tagged_above=-999 required=5 tests=[AWL=0.955, BAYES_05=-1.11, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q1GN2iH8aaNu for <ietfarch-atompub-archive@core3.amsl.com>; Wed, 13 Oct 2010 11:02:15 -0700 (PDT)
Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 2586D3A69F5 for <atompub-archive@ietf.org>; Wed, 13 Oct 2010 11:02:15 -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 o9DHihku015032 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 Oct 2010 10:44:43 -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 o9DHihHY015031; Wed, 13 Oct 2010 10:44:43 -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-qy0-f178.google.com (mail-qy0-f178.google.com [209.85.216.178]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o9DHig9R015025 for <atom-syntax@imc.org>; Wed, 13 Oct 2010 10:44:42 -0700 (MST) (envelope-from jasnell@gmail.com)
Received: by qyk35 with SMTP id 35so1175734qyk.16 for <atom-syntax@imc.org>; Wed, 13 Oct 2010 10:44:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=o5lKPBuvGZMkIUUTRA0cxnaAdt1oV6AXyj58eWvN8DE=; b=mvBs4jMmptxX0bkB0JQ9CSeyGmPVTinYf8PxDJJzCXEv3Ba4bAMyJNkajqS7xSdajM 0jW91UDpHXsE5M+YsMVzfnKXCu7fWw8i6O2sBIdO5MjF6eJHDsBAEJhFSxoNd+IWH/+T L70Atbs7kEoDUKYYDGpEg4MEl8qPzjJb0c7NQ=
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 :cc:content-type; b=ePYwPWz1XaDbtEBfpdQ2JV6Fsh9Q6Ml2AlEui2i9WM8geuQ2pMvs8/VGgWCrU6HO2X l0czPo8gOffHbe/V4LMwaPvec76/ohCpeZyOk18bt5JXzb8hMdQw0pkJxjl75xrY3bEc ikhiZBUpnsEjMxAxPNwjN/K6dZk5GzqgDZLE0=
MIME-Version: 1.0
Received: by 10.224.184.3 with SMTP id ci3mr7309264qab.312.1286991881837; Wed, 13 Oct 2010 10:44:41 -0700 (PDT)
Received: by 10.229.114.194 with HTTP; Wed, 13 Oct 2010 10:44:41 -0700 (PDT)
In-Reply-To: <AANLkTi=rttjg_jmSSQmr1Or2iLnWjti9R-Dv4eaa+dA4@mail.gmail.com>
References: <AANLkTindu=8nYPsPs2WjJPwWTY7m3avyonsTtTQ1_6SM@mail.gmail.com> <AANLkTi=rttjg_jmSSQmr1Or2iLnWjti9R-Dv4eaa+dA4@mail.gmail.com>
Date: Wed, 13 Oct 2010 10:44:41 -0700
Message-ID: <AANLkTimTQyXDcxYGzkJnMveVT1L9PNyFnw-nFC8n6_qx@mail.gmail.com>
Subject: Re: deprecate icon and logo elements?
From: James Snell <jasnell@gmail.com>
To: Antone Roundy <antone@geckotribe.com>
Cc: atom-syntax@imc.org
Content-Type: multipart/alternative; boundary=20cf302d4d5ef21eb804928325e8
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>

Concrete benefits include being able to specify the media type of the linked
resource, as well as take advantage of other extensions such as the Atom
Link Extensions I've proposed, and Google's convention of using child
elements within atom:link to provide additional metadata such as multiple
alternative representations of an image (e.g. thumbnails, etc). At the very
least, we should be able to specify the media type of the linked image.

On Wed, Oct 13, 2010 at 10:37 AM, Antone Roundy <antone@geckotribe.com>wrote;wrote:

>
> I've never been a fan of using <link> for connecting to every sort of
> external entity, since it makes it impossible to write general purpose
> <link> handling code (for unknown @rel values) without ending up doing
> things that degrade the user experience. But that battle has already
> been lost (when the idea of reserving <link> for links intended for
> traversal was rejected).
>
> The question now is, what benefit do we get in exchange for
> implementations having to be updated to look for the images in a new
> location?  If there's no concrete benefit, I'd vote for keeping it as
> it is.  It'll be simpler for new implementers if they don't have to
> discover that something in the spec has been deprecated. And it'll be
> simpler for everyone if there are fewer ways to do the same thing.
>
> Antone
>
>