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

["MUNSON, GARY A, ATTLABS" <[e-mail]>]

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