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