Re: [apps-discuss] New Version Notification for draft-wilde-atom-profile-02.txt
"Rushforth, Peter" <Peter.Rushforth@NRCan-RNCan.gc.ca> Thu, 01 August 2013 16:22 UTC
Return-Path: <Peter.Rushforth@NRCan-RNCan.gc.ca>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 556C611E8121 for <apps-discuss@ietfa.amsl.com>; Thu, 1 Aug 2013 09:22:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.999
X-Spam-Level:
X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_73=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vO-gapPJ41Pi for <apps-discuss@ietfa.amsl.com>; Thu, 1 Aug 2013 09:22:25 -0700 (PDT)
Received: from nrcan.gc.ca (s-bsc-edge1.nrcan.gc.ca [132.156.238.13]) by ietfa.amsl.com (Postfix) with ESMTP id 731E211E811E for <apps-discuss@ietf.org>; Thu, 1 Aug 2013 09:22:12 -0700 (PDT)
Received: from S-BSC-CAS2.nrn.nrcan.gc.ca (132.156.238.12) by S-BSC-EDGE1.nrcan.gc.ca (132.156.238.13) with Microsoft SMTP Server (TLS) id 14.2.342.3; Thu, 1 Aug 2013 12:22:10 -0400
Received: from S-BSC-MBX1.nrn.nrcan.gc.ca ([169.254.1.190]) by S-BSC-CAS2.nrn.nrcan.gc.ca ([fe80::48d4:f168:78ba:d4e8%19]) with mapi id 14.02.0342.003; Thu, 1 Aug 2013 12:22:10 -0400
From: "Rushforth, Peter" <Peter.Rushforth@NRCan-RNCan.gc.ca>
To: Erik Wilde <dret@berkeley.edu>
Thread-Topic: New Version Notification for draft-wilde-atom-profile-02.txt
Thread-Index: AQHOjDCI9XQy2nN2qEqEl76+2ahvXJl7we3Q
Date: Thu, 01 Aug 2013 16:22:09 +0000
Message-ID: <1CD55F04538DEA4F85F3ADF7745464AF24A50613@S-BSC-MBX1.nrn.nrcan.gc.ca>
References: <20130729071438.10957.87683.idtracker@ietfa.amsl.com> <51F61F2A.8030403@berkeley.edu>
In-Reply-To: <51F61F2A.8030403@berkeley.edu>
Accept-Language: en-CA, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [132.156.238.22]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "apps-discuss@ietf.org application-layer protocols" <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] New Version Notification for draft-wilde-atom-profile-02.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 01 Aug 2013 16:22:30 -0000
Hi dret, In general I think this is a good addition to profiles. A few points though. This specification should consider updating RFC 5023 instead of 4287, since the atomsvc+xml and atomcat+xml sub-types are defined by 5023 and could/should also leverage the profile media type parameter. In the Examples section 2.3, the draft says that clients requesting a collection from an AtomPub feed have no indication that the service supports atompub. This is not true, as the service can send the 'type=feed' media type parameter, which is defined by RFC 5023, indicating the feed has atompub support. http://tools.ietf.org/html/rfc5023#section-12 This was associated with the application/atom+xml media type by the RFC 5023 registration: http://tools.ietf.org/html/rfc5023#page-43 In the Section 1, paragraph 2, http://tools.ietf.org/html/draft-wilde-atom-profile-02#section-1 you describe a profile as being additional semantics layered on the original media type semantics so long as they don't change the semantics of the original media type, only add to them. Furthermore, in paragraph 3 you say that profiles are identified by URI. This brings to mind link relations, and its my suggestion that profiles should use the same model, i.e. a URI for a non-registered profile and a simple token for a registered profile, where the registration maintains the syntax and semantics of the profile. It would then be the 'responsibility' of the URI owner to provide a definition for the extended semantics, while a token-based profile would have its semantics in the central registry. In this way, I think, the self-describing messages constraint of REST can be respected by mime types carrying profile parameters. We have _experimentally_ implemented the profile media type parameter and link relation in our (beta) service, categories, feed and entry documents: http://geogratis.gc.ca/api/beta/en/nrcan-rncan/ http://geogratis.gc.ca/api/beta/en/nrcan-rncan/ess-sst/$categories http://geogratis.gc.ca/api/beta/en/nrcan-rncan/ess-sst/ http://geogratis.gc.ca/api/beta/en/nrcan-rncan/ess-sst/647e6de7-5192-5fb0-8631-ac3d7263e2ee Note: add ?alt=xml to the above URIs to view the xml in a browser, or negotiate for the appropriate application/atom(*)+xml to view the profile media type parameter. Any feedback would be appreciated. If you like, I will send you the requested information for the implementation section per specs below. Cheers, Peter > -----Original Message----- > From: Erik Wilde [mailto:dret@berkeley.edu] > Sent: July 29, 2013 03:52 > To: apps-discuss@ietf.org application-layer protocols; > Atom-Syntax; Atom-Protocol > Cc: REST-Discuss > Subject: Fw: New Version Notification for > draft-wilde-atom-profile-02.txt > > hello. > > a new version of draft-wilde-atom-profile has been posted. if > you are using profiles with atom, and specifically the > proposed profile media type parameter, please get in touch. > it would be great to add implementations to > http://tools.ietf.org/html/draft-wilde-atom-profile-02#section -5 (please see http://tools.ietf.org/html/rfc6982#section-2 for > a description of the implementation information needed). > > thanks and cheers, > > dret. > > ---------------------------------------------------------------------- > > On 2013-07-29 9:14 , internet-drafts@ietf.org wrote: > > A new version of I-D, draft-wilde-atom-profile-02.txt has been > > successfully submitted by Erik Wilde and posted to the IETF > > repository. > > > > Filename: draft-wilde-atom-profile > > Revision: 02 > > Title: Profile Support for the Atom Syndication Format > > Creation date: 2013-07-29 > > Group: Individual Submission > > Number of pages: 9 > > URL: > http://www.ietf.org/internet-drafts/draft-wilde-atom-profile-02.txt > > Status: > http://datatracker.ietf.org/doc/draft-wilde-atom-profile > > Htmlized: > http://tools.ietf.org/html/draft-wilde-atom-profile-02 > > Diff: > http://www.ietf.org/rfcdiff?url2=draft-wilde-atom-profile-02 > > > > Abstract: > > The Atom syndication format is a generic XML format for > representing > > collections. Profiles are one way how Atom feeds can > indicate that > > they support specific extensions. To make this support > visible on > > the media type level, this specification adds an > optional "profile" > > media type parameter to the Atom media type. This > allows profiles to > > become visible at the media type level, so that servers > as well as > > clients can indicate support for specific Atom profiles in > > conversations, for example when communicating via HTTP. This > > specification updates RFC 4287 by adding the "profile" > media type > > parameter to the application/atom+xml media type registration. >
- [apps-discuss] Fw: New Version Notification for d… Erik Wilde
- Re: [apps-discuss] New Version Notification for d… Rushforth, Peter