[apps-discuss] Deprecation mechanism in JSON HOme Documents

algermissen1971 <algermissen1971@me.com> Mon, 25 February 2013 08:04 UTC

Return-Path: <algermissen1971@me.com>
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 B8B2D21F920D for <apps-discuss@ietfa.amsl.com>; Mon, 25 Feb 2013 00:04:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8qxsiVWLvId2 for <apps-discuss@ietfa.amsl.com>; Mon, 25 Feb 2013 00:04:21 -0800 (PST)
Received: from nk11p03mm-asmtp002.mac.com (nk11p03mm-asmtpout002.mac.com [17.158.232.237]) by ietfa.amsl.com (Postfix) with ESMTP id C5B6621F9221 for <apps-discuss@ietf.org>; Mon, 25 Feb 2013 00:04:20 -0800 (PST)
Received: from [172.20.10.2] ([80.187.106.152]) by nk11p03mm-asmtp002.mac.com (Oracle Communications Messaging Server 7u4-26.01(7.0.4.26.0) 64bit (built Jul 13 2012)) with ESMTPSA id <0MIR00JJWNQTYE60@nk11p03mm-asmtp002.mac.com> for apps-discuss@ietf.org; Mon, 25 Feb 2013 08:04:13 +0000 (GMT)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.9.8327, 1.0.431, 0.0.0000 definitions=2013-02-25_02:2013-02-22, 2013-02-25, 1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=41 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1203120001 definitions=main-1302250000
From: algermissen1971 <algermissen1971@me.com>
Content-type: text/plain; charset="us-ascii"
Content-transfer-encoding: quoted-printable
Message-id: <1AD639E1-35D3-4F17-8C4C-FFD2CC2CAE5C@me.com>
Date: Mon, 25 Feb 2013 09:04:06 +0100
To: "apps-discuss@ietf.org" <apps-discuss@ietf.org>
MIME-version: 1.0 (Mac OS X Mail 6.2 \(1499\))
X-Mailer: Apple Mail (2.1499)
X-Mailman-Approved-At: Thu, 28 Feb 2013 00:31:44 -0800
Subject: [apps-discuss] Deprecation mechanism in JSON HOme Documents
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: Mon, 25 Feb 2013 08:04:22 -0000

Hi Mark,

in your latest draft of JSON Homep[1] you define a deprecation mechanism that allows a provider to provide a hint to a consumer that a certain described resource is in a deprecation period.

As designed now, this mechanism cannot be used to hint the deprecation of a certain provided media type:

Suppose I have 


"http://example.org/rel/widgets": {
  "href": "/widgets/",
  "hints": {
    "representations": ["application/widgetlist"]
  }
}

and at some point, I have to evolve the media type in an incompatible way, yielding a new media type 'application/special-new-widgetlist'. To support both, new and old clients, I'd let the types coexist:

"http://example.org/rel/widgets": {
  "href": "/widgets/",
  "hints": {
    "representations": ["application/widgetlist","application/special-new-widgetlist"],
  }
}

As time passes and clients pick up the shiny new media type, a point is reached where I want to hint older clients that an upgrade is in order. I'd like to deprecate the availability of the older media type 'application/widgetlist'.

However ... that is impossible right now since 'deprecated' only applies to the resource as a whole - which I deliberately do *not* want to change or remove.

What are your thoughts? Is there a certain design decision behind your approach that I am not seeing? 

What do you think of augmenting the deprecation mechanism to something like:

"http://example.org/rel/widgets": {
  "href": "/widgets/",
  "hints": {
    "representations": ["application/widgetlist","application/special-new-widgetlist"],
    "deprecated-representations" : ["application/widgetlist"]
  }
}

Jan


[1] http://tools.ietf.org/html/draft-nottingham-json-home-02