IETF Logo Mail Archive

Re: deprecate icon and logo elements?

Antone Roundy <antone@geckotribe.com> Wed, 13 October 2010 17:41 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 E02B23A6A12 for <ietfarch-atompub-archive@core3.amsl.com>; Wed, 13 Oct 2010 10:41:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.424
X-Spam-Level:
X-Spam-Status: No, score=-1.424 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553]
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 AlataCX38d-t for <ietfarch-atompub-archive@core3.amsl.com>; Wed, 13 Oct 2010 10:41:50 -0700 (PDT)
Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 751A13A6BAB for <atompub-archive@ietf.org>; Wed, 13 Oct 2010 10:41:19 -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 o9DHbaH2014716 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 Oct 2010 10:37:36 -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 o9DHbagG014715; Wed, 13 Oct 2010 10:37:36 -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-yw0-f43.google.com (mail-yw0-f43.google.com [209.85.213.43]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o9DHbYa1014702 for <atom-syntax@imc.org>; Wed, 13 Oct 2010 10:37:36 -0700 (MST) (envelope-from electriceel@gmail.com)
Received: by ywa8 with SMTP id 8so2279189ywa.16 for <atom-syntax@imc.org>; Wed, 13 Oct 2010 10:37:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=C3akoNLxIcvUEVPNGN0vZF+yLa9hA6pzshCSWG7oaHc=; b=ajsRPa/668A2IVBjQqnYhEBjJXd/SpYe1h5Qd1y838gyzOU1LW8EFqNKHj0w1EZYDv krnlWzuJ3eZxABkbQVp48UMSPCbixXxdu79frJDz6yH/mf5kDdqbzx6LgJLknWqb4VsM cCeFqTStm4GIpBNRg+E0UtE/iipKb/yWtILFA=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; b=VH+Vhw5oYhp49MeyzAvAymYdYw3FdLXSv3U8XJeimN0TvS89dKxA8c6d2R2AwVa+TX aUk+L4wcbuJLl/vxxPXL2Y/3bTo91acku+atbbA51vQerGu5KyH+nIF9AW9t7BJAS3fu ugHTJAyCNB7+aoPYhzucLS11KBHu1sLmMz0iU=
MIME-Version: 1.0
Received: by 10.42.180.201 with SMTP id bv9mr95699icb.103.1286991452999; Wed, 13 Oct 2010 10:37:32 -0700 (PDT)
Received: by 10.231.206.138 with HTTP; Wed, 13 Oct 2010 10:37:32 -0700 (PDT)
In-Reply-To: <AANLkTindu=8nYPsPs2WjJPwWTY7m3avyonsTtTQ1_6SM@mail.gmail.com>
References: <AANLkTindu=8nYPsPs2WjJPwWTY7m3avyonsTtTQ1_6SM@mail.gmail.com>
Date: Wed, 13 Oct 2010 12:37:32 -0500
X-Google-Sender-Auth: MzA3lTc3PWJd4wobVhApdbtJ52o
Message-ID: <AANLkTi=rttjg_jmSSQmr1Or2iLnWjti9R-Dv4eaa+dA4@mail.gmail.com>
Subject: Re: deprecate icon and logo elements?
From: Antone Roundy <antone@geckotribe.com>
To: 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>

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

v2.8.7 | Report a Bug | By Email