[MEDIACTRL] ISSUE 4 - IVR Package - <record> append

"McGlashan, Scott" <scott.mcglashan@hp.com> Thu, 07 October 2010 18:11 UTC

Return-Path: <scott.mcglashan@hp.com>
X-Original-To: mediactrl@core3.amsl.com
Delivered-To: mediactrl@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 385093A7258 for <mediactrl@core3.amsl.com>; Thu, 7 Oct 2010 11:11:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.932
X-Spam-Level:
X-Spam-Status: No, score=-105.932 tagged_above=-999 required=5 tests=[AWL=0.667, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 erkybil4BgrG for <mediactrl@core3.amsl.com>; Thu, 7 Oct 2010 11:11:02 -0700 (PDT)
Received: from g4t0014.houston.hp.com (g4t0014.houston.hp.com [15.201.24.17]) by core3.amsl.com (Postfix) with ESMTP id A58E33A717D for <mediactrl@ietf.org>; Thu, 7 Oct 2010 11:11:02 -0700 (PDT)
Received: from G1W0400.americas.hpqcorp.net (g1w0400.americas.hpqcorp.net [16.236.31.10]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by g4t0014.houston.hp.com (Postfix) with ESMTPS id 23B4024808; Thu, 7 Oct 2010 18:12:05 +0000 (UTC)
Received: from G6W0173.americas.hpqcorp.net (16.230.33.182) by G1W0400.americas.hpqcorp.net (16.236.31.10) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 7 Oct 2010 18:10:58 +0000
Received: from GVW1124EXC.americas.hpqcorp.net ([16.228.24.184]) by G6W0173.americas.hpqcorp.net ([16.230.33.182]) with mapi; Thu, 7 Oct 2010 18:08:59 +0000
From: "McGlashan, Scott" <scott.mcglashan@hp.com>
To: "mediactrl@ietf.org" <mediactrl@ietf.org>
Date: Thu, 07 Oct 2010 18:10:50 +0000
Thread-Topic: ISSUE 4 - IVR Package - <record> append
Thread-Index: ActmSv1nBVytziezTKOx0HPAIAv/IA==
Message-ID: <C8D3D9CA.9524%Scott.McGlashan@hp.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.0.0.100802
acceptlanguage: en-US
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: Melnikov Alexey <alexey.melnikov@isode.com>, "mediactrl-chairs@tools.ietf.org" <mediactrl-chairs@tools.ietf.org>, "draft-ietf-mediactrl-ivr-control-package@tools.ietf.org" <draft-ietf-mediactrl-ivr-control-package@tools.ietf.org>
Subject: [MEDIACTRL] ISSUE 4 - IVR Package - <record> append
X-BeenThere: mediactrl@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Media Control WG Discussion List <mediactrl.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mediactrl>, <mailto:mediactrl-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mediactrl>
List-Post: <mailto:mediactrl@ietf.org>
List-Help: <mailto:mediactrl-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mediactrl>, <mailto:mediactrl-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Oct 2010 18:11:10 -0000

Fourth (and final I think) issue for mailing list discussion following IESG review of the IVR package:

In 4.3.1.4:

   append:  indicates whether recorded data is appended or not to a
      recording location if a resource already exists.  A valid value is
      a boolean (see Section 4.6.1).  A value of true indicates that
      recorded data is appended to the existing resource at a recording
      location.  A value of false indicates that recorded data is to
      overwrite the existing resource.  The attribute is optional.  The
      default value is false.

How is append/overwrite mapped to underlying protocol being used?
In particular, I think this is underspecified in case of HTTP.

This is a good point and we don't say anything about how to map record upload to the underlying protocol. Since we mandated HTTP (and HTTPS), I'd prefer if we specify a mapping to HTTP. I'd propose something like:

When a recording location is specified using the HTTP or HTTPS protocol, the recording operation is mapped to the HTTP POST and PUT operations depending on whether the append attribute is true or false:

1. append = false. The recording data is uploaded to the specified location using HTTP PUT and replaces any data that location on the origin server. Success if the origin server returns 201 (Created); any other HTTP response is treated as an upload error.

2. append = true. The recording data is uploaded to the specified location using HTTP POST and is added to the resource - if any - at that location. Success if the origin server returns 204 (No Content) or 205 (Reset Content); any other HTTP response is treated as an upload error.

Let me know if you think this is along the right lines – any improvements (or other implementation experiences) welcome.  The other alternative is to delete the append attribute – especially if  no-one implements it .. If we do decide to delete the append attribute, I still think some text around the HTTP protocol mapping is useful.

Thanks

Scott