Re: [splices] SIP INVOKE method v1

Alan Johnston <alan.b.johnston@gmail.com> Tue, 14 June 2011 17:45 UTC

Return-Path: <alan.b.johnston@gmail.com>
X-Original-To: splices@ietfa.amsl.com
Delivered-To: splices@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1D1411E8192 for <splices@ietfa.amsl.com>; Tue, 14 Jun 2011 10:45:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.599
X-Spam-Level:
X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
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 s0iZrX2YBmPY for <splices@ietfa.amsl.com>; Tue, 14 Jun 2011 10:45:42 -0700 (PDT)
Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2A40711E8140 for <splices@ietf.org>; Tue, 14 Jun 2011 10:45:41 -0700 (PDT)
Received: by yie30 with SMTP id 30so2186851yie.31 for <splices@ietf.org>; Tue, 14 Jun 2011 10:45:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=sc/g9ouVnG3O3I23+SLL4DV5gSBOYoAsKPg4kna9R8g=; b=rS7Lj+D03vmrG/LwQofSJq1OJqy4tsPN8Wb1DTgOLzl4cdjzWD+94OLYnaz+fpCiLm FfKRZacj3M248+A4nUWr+AZZf0Z1GcyRqbJFvy8BNCde0x+BvJcAX0ryVZylf/5E7Npi CpBev8c/Hexq9TaVhYimeS7gLs3oOc0AgLQdg=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Wpm8NPPD0+h04O6VUuvGOUoEYCTnWGof9hEdH1g/A9SSnJ7GRgECE9iUI4EOQTSUxp PNeVaHgjZybwG12q3YvVZkLlyyVbBPspW0kfjx5wRcRR5w9FQgGncUvax8jw/R1JYnxA 53JF8WcpVSAOj+e5nSwk53gmnyi7JzvCbns/0=
MIME-Version: 1.0
Received: by 10.150.61.8 with SMTP id j8mr7867318yba.219.1308073541246; Tue, 14 Jun 2011 10:45:41 -0700 (PDT)
Received: by 10.151.79.8 with HTTP; Tue, 14 Jun 2011 10:45:41 -0700 (PDT)
In-Reply-To: <CD5674C3CD99574EBA7432465FC13C1B222907E9D3@DC-US1MBEX4.global.avaya.com>
References: <6369CB70BFD88942B9705AC1E639A33822CD81384C@DC-US1MBEX4.global.avaya.com> <4DF27461.8060204@cisco.com> <101C6067BEC68246B0C3F6843BCCC1E30C22977E6A@MCHP058A.global-ad.net> <6369CB70BFD88942B9705AC1E639A33822CDA812C4@DC-US1MBEX4.global.avaya.com> <101C6067BEC68246B0C3F6843BCCC1E30C229785C2@MCHP058A.global-ad.net> <CD5674C3CD99574EBA7432465FC13C1B222907E9D3@DC-US1MBEX4.global.avaya.com>
Date: Tue, 14 Jun 2011 12:45:41 -0500
Message-ID: <BANLkTimdTmoZ7fDz7wOVBPCPS0WxrRfJoQ@mail.gmail.com>
From: Alan Johnston <alan.b.johnston@gmail.com>
To: "Worley, Dale R (Dale)" <dworley@avaya.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: "splices@ietf.org" <splices@ietf.org>
Subject: Re: [splices] SIP INVOKE method v1
X-BeenThere: splices@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Loosely-coupled SIP Devices \(splices\) working group discussion list" <splices.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/splices>, <mailto:splices-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/splices>
List-Post: <mailto:splices@ietf.org>
List-Help: <mailto:splices-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/splices>, <mailto:splices-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 14 Jun 2011 17:45:42 -0000

Andy,

I agree with Dale that the set of actions should be small, otherwise,
we are doing something else.  Also, the set of parameters needs to be
small.  In fact, I think most actions won't have any parameters at
all.  This is why we are using URNs, just names, for the actions.

To do otherwise is to introduce complex actions or scripts, and I
don't want this mechanism to be used for that.  There are other
mechanisms (e.g. CPL) that allows a script to be uploaded or
downloaded to control a UA or proxy operation, but that is very
different from what we are talking about here.

I agree that we could discuss BNF vs XML, but if we agree that we
really are dealing with URNs, then a header makes more sense than a
body.

- Alan -

On Tue, Jun 14, 2011 at 12:32 PM, Worley, Dale R (Dale)
<dworley@avaya.com> wrote:
>> From: Hutton, Andrew [andrew.hutton@siemens-enterprise.com]
>>
>> The list of potential actions and associated parameters is huge and
>> for this kind of problem I believe that an XML body would be a much
>> better solution. I guess I much prefer XML to BNF.
>
> I'd feel much more comfortable if we settled on either:
>
> 1) a small number of actions
>
> 2) to use an appropriate subset of an existing CTI standard
>
> In the latter case, could someone provide a pointer to the standard?
>
> Essentially, INVOKE is to provide an interface to a command set, and
> we need to have some idea what the outer limits of the command set
> will be.  Only then can we choose a good way to represent the commands
> within a SIP request.
>
> Dale
> _______________________________________________
> splices mailing list
> splices@ietf.org
> https://www.ietf.org/mailman/listinfo/splices
>