[MEDIACTRL] ISSUE 3 - IVR Package - <variable>/<variabletype> interoperability

"McGlashan, Scott" <scott.mcglashan@hp.com> Thu, 07 October 2010 09:33 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 DEEF73A6FC0 for <mediactrl@core3.amsl.com>; Thu, 7 Oct 2010 02:33:17 -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 lk7qFsXm+LkM for <mediactrl@core3.amsl.com>; Thu, 7 Oct 2010 02:32:37 -0700 (PDT)
Received: from g1t0027.austin.hp.com (g1t0027.austin.hp.com [15.216.28.34]) by core3.amsl.com (Postfix) with ESMTP id E24F93A6F67 for <mediactrl@ietf.org>; Thu, 7 Oct 2010 02:32:24 -0700 (PDT)
Received: from G6W0640.americas.hpqcorp.net (g6w0640.atlanta.hp.com [16.230.34.76]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by g1t0027.austin.hp.com (Postfix) with ESMTPS id 8D561387B0; Thu, 7 Oct 2010 09:33:26 +0000 (UTC)
Received: from G5W0323.americas.hpqcorp.net (16.228.8.68) by G6W0640.americas.hpqcorp.net (16.230.34.76) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 7 Oct 2010 09:31:40 +0000
Received: from GVW1124EXC.americas.hpqcorp.net ([16.228.24.184]) by G5W0323.americas.hpqcorp.net ([16.228.8.68]) with mapi; Thu, 7 Oct 2010 09:31:40 +0000
From: "McGlashan, Scott" <scott.mcglashan@hp.com>
To: "mediactrl@ietf.org" <mediactrl@ietf.org>
Date: Thu, 7 Oct 2010 09:31:38 +0000
Thread-Topic: ISSUE 3 - IVR Package - <variable>/<variabletype> interoperability
Thread-Index: ActmAnI3K60cVII+QCmfuxBebzZbzQ==
Message-ID: <C8D3601A.9394%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="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: Melnikov <alexey.melnikov@isode.com>, "Alexey@core3.amsl.com" <Alexey@core3.amsl.com>, "mediactrl-chairs@tools.ietf.org" <mediactrl-chairs@tools.ietf.org>, "stpeter@stpeter.im" <stpeter@stpeter.im>, "draft-ietf-mediactrl-ivr-control-package@tools.ietf.org" <draft-ietf-mediactrl-ivr-control-package@tools.ietf.org>
Subject: [MEDIACTRL] ISSUE 3 - IVR Package - <variable>/<variabletype> interoperability
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 09:33:18 -0000

Hi All,

As part of our IESG review of the IVR package the following issues have been identified:

(a) 4.3.1.1.1.  <variable>

   A <variable> element has the following attributes:

   value:  specifies the string to be rendered.  A valid value is a
      string (see Section 4.6.6).  The attribute is mandatory.

   type:  specifies the type to use for rendering.  A valid value is a
      string (see Section 4.6.6).  The attribute is mandatory.

   format:  specifies format information to use in conjunction with the
      type for the rendering.  A valid value is a string (see
      Section 4.6.6).  The attribute is optional.  There is no default
      value.

 Are these defined somewhere in more details?

   For example, the MS could support <variable> type/format combinations
   such as:

 Is this the complete list?


(b) Please clarify how implementations will achieve interoperability with regard to the <variable> element, given that there are no registries or specification for the 'type' and 'format' attributes. This applies also to the <variabletype> element.


We need some input from the mailing list on how we should proceed with this one: some options

1. Strengthen our descriptions of date, time and digits format/types. Limit interoperability requirements to these 3 types.

2. As 1), but introduce registry for adding additional types.

3. Delete the <variable> and <variabletype> elements.


I would like WG input on these options. My preference is for option 2 (or option 1 as 2nd choice).

Thanks

Scott