[MEDIACTRL] New MRB document (-04)

"Lorenzo Miniero" <lorenzo@meetecho.com> Tue, 30 March 2010 20:04 UTC

Return-Path: <lorenzo@meetecho.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 18B8B3A691C for <mediactrl@core3.amsl.com>; Tue, 30 Mar 2010 13:04:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.011
X-Spam-Level: ***
X-Spam-Status: No, score=3.011 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245]
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 lOFmOS6LZT7P for <mediactrl@core3.amsl.com>; Tue, 30 Mar 2010 13:04:07 -0700 (PDT)
Received: from smtp1.aruba.it (smtp2.aruba.it [62.149.128.201]) by core3.amsl.com (Postfix) with SMTP id 1C2993A68CC for <mediactrl@ietf.org>; Tue, 30 Mar 2010 13:04:05 -0700 (PDT)
Received: (qmail 17246 invoked by uid 89); 30 Mar 2010 20:04:25 -0000
Received: from unknown (HELO aruba.it) (10.10.10.97) by smtp1.ad.aruba.it with SMTP; 30 Mar 2010 20:04:25 -0000
Date: Tue, 30 Mar 2010 22:04:27 +0200
Message-Id: <L042FF$134FE4783B95D232F07EEC807A863331@aruba.it>
MIME-Version: 1.0
X-Sensitivity: 3
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: Lorenzo Miniero <lorenzo@meetecho.com>
To: mediactrl@ietf.org
X-XaM3-API-Version: V3(R1)
X-SenderIP: 79.47.152.84
X-Spam-Rating: smtp1.ad.aruba.it 1.6.2 0/1000/N
Subject: [MEDIACTRL] New MRB document (-04)
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: Tue, 30 Mar 2010 20:04:09 -0000

Dear all,

Chris and I have just uploaded an updated version of the MRB doc.

The new document addresses all the relevant points of discussion raised during the meeting in Anaheim, and the related decisions taken there accordingly. It also takes into account the whole RAI expert review by Ben. A lot of text has been also added to clarify some of the more obscure points, and as such the document should be more readable.

That said, the document is basically complete now, but still needs your feedback on a couple of small remaining issues, that were also discussed in Anaheim. They are relatively minor issues, and as soon as they will be solved we'll integrate the results in a new document to be made available immediately thereafter.



1) caller-prefs

The issue was raised by Ben in his review. While during the discussion it was generally agreed that the set of Consumer-related information is exactly the same when using either HTTP (Query) or SIP (IAMM) as a transport, meaning custom options in the SIP header in the SIP case may not be needed, it was also suggested to report the issue on the ML for further discussion. I admit I'm not familiar with the specification, so I'll gladly accept any guidance you'll provide us with on how to proceed in that sense, if necessary.



2) Required/Support header in SIP

Ben also pointed out that a proper piece of information, an option tag, may be needed in the Required/Supported headers for the Consumer-over-SIP case to address the use of multipart/mixed payloads in IAMM. A proper name for the option tag, considering the use case, might be just 'iamm'. Is it acceptable to specify such information in this document (and if so, is there any guideline that should be followed), or is it something that falls instead under the responsibility of other WGs, e.g., SIPCORE?



3) Extensibiliy of the schemas

This is the last issue. Both the schemas are already extensible in all their parts, except for the fields that are currently defined as enumerations. It is the case, as specified during the meeting, of:

	msstatus: {active, deactivated, unavailable}
	action: {create, update, remove}
	actions: {encoding, decoding, passthrough}
	dtmf: {RFC4733, Media}
	vxml: {RFC5552, IVR-Package}

The extensibility of enumerations in XML schemas is a well known issue, and several different solutions have been proposed to take care of it, each one with pros and cons.

The way Chris and I are thinking to proceed is to implement such extensibility by recurring to the "union" approach. To make a practical example, consider 'msstatus':

  ## OLD ##

  <xsd:simpleType name="msstatus.datatype">
   <xsd:restriction base="xsd:NMTOKEN">
    <xsd:enumeration value="active" />
    <xsd:enumeration value="deactivated" />
    <xsd:enumeration value="unavailable" />
   </xsd:restriction>
  </xsd:simpleType>

  ## NEW ##

  <xsd:simpleType name="known-msstatus.datatype">
   <xsd:restriction base="xsd:NMTOKEN">
    <xsd:enumeration value="active" />
    <xsd:enumeration value="deactivated" />
    <xsd:enumeration value="unavailable" />
   </xsd:restriction>
  </xsd:simpleType>

  <xsd:simpleType name="msstatus.datatype">
   <xsd:union memberTypes="known-msstatus.datatype xsd:NMTOKEN" />
  </xsd:simpleType>

The trick basically consists in defining the enumeration in a helper type, and then define the actually used type as an union between the enumeration and a generic type (e.g., a string). This would allow for extensibility, since validators wouldn't barf when finding in 'msstatus' an unexpected value, i.e., something not belonging to the restricted enumeration set. Nevertheless, it also would allow any content to be provided in 'msstatus' without violating the schema: such control should be done at the application layer, and some may not like it.

That said, are you ok with this, or do you prefer a dfferent approach?

 ## POSSIBLE SOLUTIONS! ##

   1) stick to the enumerators and don't care about extensibility for those fields (not liked in Anaheim)
   2) exploit the "union" trick to allow for extensibility (and live with the fact that it loosens constraints at the XML level)
   3) have you faced such an issue in previous specifications? if so, any guidance on better solutions?



That's all, we hope to hear from you soon, thanks!
Chris and Lorenzo

--
Lorenzo Miniero
http://www.meetecho.com