Re: [MEDIACTRL] New MRB document (-04)

Lorenzo Miniero <lorenzo@meetecho.com> Wed, 31 March 2010 08:33 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 DB5A23A68CB for <mediactrl@core3.amsl.com>; Wed, 31 Mar 2010 01:33:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.411
X-Spam-Level:
X-Spam-Status: No, score=0.411 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 eWTwpG3XBvgH for <mediactrl@core3.amsl.com>; Wed, 31 Mar 2010 01:33:42 -0700 (PDT)
Received: from smtp6.aruba.it (smtpd3.aruba.it [62.149.128.208]) by core3.amsl.com (Postfix) with SMTP id 9608C3A672F for <mediactrl@ietf.org>; Wed, 31 Mar 2010 01:33:07 -0700 (PDT)
Received: (qmail 28295 invoked by uid 89); 31 Mar 2010 08:33:28 -0000
Received: from unknown (HELO lminiero-acer) (lorenzo@meetecho.com@143.225.229.166) by smtp6.ad.aruba.it with SMTP; 31 Mar 2010 08:33:28 -0000
Date: Wed, 31 Mar 2010 10:31:56 +0200
From: Lorenzo Miniero <lorenzo@meetecho.com>
To: "MUNSON, GARY A, ATTLABS" <gm3472@att.com>
Message-Id: <20100331103156.eb0a4c96.lorenzo@meetecho.com>
In-Reply-To: <2F41EF28ED42A5489E41742244C9117C0224B6B0@gaalpa1msgusr7b.ugd.att.com>
References: <L042FF$134FE4783B95D232F07EEC807A863331@aruba.it> <2F41EF28ED42A5489E41742244C9117C0224B6B0@gaalpa1msgusr7b.ugd.att.com>
Organization: Meetecho
X-Mailer: Sylpheed 2.6.0 (GTK+ 2.16.6; i586-redhat-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Spam-Rating: smtp6.ad.aruba.it 1.6.2 0/1000/N
Cc: mediactrl@ietf.org
Subject: Re: [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: Wed, 31 Mar 2010 08:33:44 -0000

Hi Gary,

I forgot to thank you for your feedback in that mail (I do it now!),
many of the comments you provided there were taken to the face to face
meeting in Anaheim, so I also pointed out your thoughts about
caller-prefs. I do agree with you that there probably is not a need for
such a mechanism. Nevertheless, the feeling in the audience was to relay
the discussion on the ML, which is why I reported it in the post.

Thanks,
Lorenzo


On Wed, 31 Mar 2010 00:34:36 -0400
"MUNSON, GARY A, ATTLABS" <gm3472@att.com> wrote:

> Hi Lorenzo & Chris,
> 
> I don't have any opinion or wisdom on (2) or (3) below.
> 
> Regarding (1) about caller-pref, I appreciate why the question was
> asked, at least at first glance, but it doesn't seem like something
> fruitful to pursue (as I said in my March 24 email). Using the same
> approach for describing MS attributes in SIP as with HTTP is a better
> case of re-use, as we have done. And a bi-modal AS or bi-modal MRB
> doesn't have to populate/receive MS information differently. And I don't
> see extending caller preferences to support MRB selection of an MS as
> trivial or even natural (where does the lease mechanism fit in, or how
> about asking for multiple ports in one request?) 
> 
> Cheers,
> 
> Gary
> 
> -----Original Message-----
> From: mediactrl-bounces@ietf.org [mailto:mediactrl-bounces@ietf.org] On
> Behalf Of Lorenzo Miniero
> Sent: Tuesday, March 30, 2010 4:04 PM
> To: mediactrl@ietf.org
> Subject: [MEDIACTRL] New MRB document (-04)
> 
> 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
> 
> _______________________________________________
> MEDIACTRL mailing list
> MEDIACTRL@ietf.org
> https://www.ietf.org/mailman/listinfo/mediactrl
> Supplemental Web Site:
> http://www.standardstrack.com/ietf/mediactrl
> 


-- 
Lorenzo Miniero
Meetecho s.r.l.
http://www.meetecho.com/