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

Victor Paulsamy <vpaulsamy@ditechnetworks.com> Thu, 07 October 2010 21:55 UTC

Return-Path: <vpaulsamy@ditechnetworks.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 574E13A6F57 for <mediactrl@core3.amsl.com>; Thu, 7 Oct 2010 14:55:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.976
X-Spam-Level:
X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001]
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 qI3YMXUzqKIO for <mediactrl@core3.amsl.com>; Thu, 7 Oct 2010 14:55:51 -0700 (PDT)
Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id B310C3A6E7D for <mediactrl@ietf.org>; Thu, 7 Oct 2010 14:55:50 -0700 (PDT)
Received: by ewy21 with SMTP id 21so272497ewy.31 for <mediactrl@ietf.org>; Thu, 07 Oct 2010 14:56:50 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.213.59.76 with SMTP id k12mr2041934ebh.13.1286488608211; Thu, 07 Oct 2010 14:56:48 -0700 (PDT)
Received: by 10.213.28.73 with HTTP; Thu, 7 Oct 2010 14:56:48 -0700 (PDT)
In-Reply-To: <C8D3D9CA.9524%Scott.McGlashan@hp.com>
References: <C8D3D9CA.9524%Scott.McGlashan@hp.com>
Date: Fri, 8 Oct 2010 04:56:48 +0700
Message-ID: <AANLkTi=yAQwAaejtQZEDFE5eocAMKCUijQ9btJ-fFzDv@mail.gmail.com>
From: Victor Paulsamy <vpaulsamy@ditechnetworks.com>
To: "McGlashan, Scott" <scott.mcglashan@hp.com>
Content-Type: multipart/alternative; boundary=00148531b6a580062704920df8bc
Cc: Melnikov Alexey <alexey.melnikov@isode.com>, "draft-ietf-mediactrl-ivr-control-package@tools.ietf.org" <draft-ietf-mediactrl-ivr-control-package@tools.ietf.org>, "mediactrl-chairs@tools.ietf.org" <mediactrl-chairs@tools.ietf.org>, "mediactrl@ietf.org" <mediactrl@ietf.org>
Subject: Re: [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 21:55:52 -0000

It should be possible to create new resource as well as append to an
existing one and hence, don't remove append option.

The text, for 1 and 2 below, satisfies my requirements.

--victor

On Fri, Oct 8, 2010 at 1:10 AM, McGlashan, Scott <scott.mcglashan@hp.com>wrote;wrote:

> 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
> _______________________________________________
> MEDIACTRL mailing list
> MEDIACTRL@ietf.org
> https://www.ietf.org/mailman/listinfo/mediactrl
> Supplemental Web Site:
> http://www.standardstrack.com/ietf/mediactrl
>