Link Extensions in the empty namespace
Niklas Lindström <lindstream@gmail.com> Tue, 05 April 2011 12:58 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 D5D1A28C0FE for <ietfarch-atompub-archive@core3.amsl.com>; Tue, 5 Apr 2011 05:58:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.299
X-Spam-Level:
X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
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 xf9pZ-Zsyf0u for <ietfarch-atompub-archive@core3.amsl.com>; Tue, 5 Apr 2011 05:58:00 -0700 (PDT)
Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2001:4870:a30c:41::81]) by core3.amsl.com (Postfix) with ESMTP id 5197A3A67B2 for <atompub-archive@ietf.org>; Tue, 5 Apr 2011 05:58:00 -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 p35CLl2Z044702 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 Apr 2011 05:21:47 -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 p35CLlvg044701; Tue, 5 Apr 2011 05:21:47 -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-pw0-f43.google.com (mail-pw0-f43.google.com [209.85.160.43]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p35CLlEC044695 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL) for <atom-syntax@imc.org>; Tue, 5 Apr 2011 05:21:47 -0700 (MST) (envelope-from lindstream@gmail.com)
Received: by pwj4 with SMTP id 4so192364pwj.16 for <atom-syntax@imc.org>; Tue, 05 Apr 2011 05:21:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:from:date:message-id:subject:to :content-type:content-transfer-encoding; bh=7+/kM368TmZYdrUeHXV4rgSmfd0akrIc6vIi+nBmIqg=; b=NJgqhzbNnjFZfds/3hAkBrD8Ydf+8I45jDRebHRN9nFX7xenFGEd/nzjvbSlhJkgbF nZc5BzurxdvHmhi0BVZHoZwGMY9WwGlXOTbOtXINNV9kj/oEH1RzRWL1qp5XPWiB07hy HatqBh+U63nncUM/1Lf2YJQaza0PjwuoH9nTE=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type :content-transfer-encoding; b=RVRa6ykfztf62XXGAwjHhC1Ia0+6TklbPfJgWKoRXETYe8SYfFf0CP+SN+T7khmPJ4 ndEWNHvpIr+GE0Bk3pERJKUFoQwBJ0uMKu/vYdbwKCU7QRjAwtlGkGqNyt4cNtbsXylP 0pf2cepjGAoOnclY6kUFD7Gf+bJWlOxbIXXhg=
Received: by 10.142.237.17 with SMTP id k17mr7450651wfh.41.1302006106002; Tue, 05 Apr 2011 05:21:46 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.68.58.129 with HTTP; Tue, 5 Apr 2011 05:21:21 -0700 (PDT)
From: Niklas Lindström <lindstream@gmail.com>
Date: Tue, 05 Apr 2011 14:21:21 +0200
Message-ID: <BANLkTimCK32_RgL12miEHhWF51HoB22drw@mail.gmail.com>
Subject: Link Extensions in the empty namespace
To: James M Snell <jasnell@gmail.com>, atom-syntax <atom-syntax@imc.org>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by hoffman.proper.com id p35CLlEB044696
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>
James, all,
I have one concern regarding the current Link Extensions ID [1]. It
currently defines attributes in the empty namespace. This causes feed
validators, e.g. [2] and [3] to complain with:
"Unexpected hash attribute on link element"
when I try to validate e.g. [4].
I suppose formally, when the Link Extensions becomes an RFC, this
updates RFC 4287 (as stated) so at that time, this should be updated
in the validators? Still, currently (and for a time after the RFC
status) it may be problematic. Since 4287 only normatively allows for
namespaced extensions I'm not sure how tools generally might handle
this (I've used Abdera in Java which copes just fine though).
Also, is there any prognosis when this might become a final RFC? (As
with tombstones, we (the swedish legal information project) need and
actively use these.)
Best regards,
Niklas Lindström
--
<http://neverspace.net/>
[1]: http://tools.ietf.org/html/draft-snell-atompub-link-extensions-08
[2]: http://feedvalidator.org/
[3]: http://validator.w3.org/feed/
[4]: http://rinfo.lagrummet.se/feed/current
- Link Extensions in the empty namespace Niklas Lindström