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

[Victor Paulsamy <[e-mail]>]

All,

I concur with Gary's -- I don't see caller prefs as a criteria to select a
MS.

--victor

On Tue, Mar 30, 2010 at 9:34 PM, MUNSON, GARY A, ATTLABS <[e-mail]>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: [e-mail] [mailto:[e-mail]] On
> Behalf Of Lorenzo Miniero
> Sent: Tuesday, March 30, 2010 4:04 PM
> To: [e-mail]
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mediactrl
> Supplemental Web Site:
> http://www.standardstrack.com/ietf/mediactrl
> _______________________________________________
> MEDIACTRL mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mediactrl
> Supplemental Web Site:
> http://www.standardstrack.com/ietf/mediactrl
>