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

From: "Lorenzo Miniero" <[email-masked]>
Date: Tue, 30 Mar 2010 22:04:27 +0200

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

---

From: "MUNSON, GARY A, ATTLABS" <[email-masked]>
Date: Wed, 31 Mar 2010 00:34:36 -0400

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: [email-masked] [mailto:[email-masked]] On
Behalf Of Lorenzo Miniero
Sent: Tuesday, March 30, 2010 4:04 PM
To: [email-masked]
Subject: [MEDIACTRL] New MRB document (-04)

Dear all,

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.

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?

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:

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 ##

  ## NEW ##

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.

   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?

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

_______________________________________________
MEDIACTRL mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mediactrl
Supplemental Web Site:
http://www.standardstrack.com/ietf/mediactrl

---

From: Chris Boulton <[email-masked]>
Date: Wed, 31 Mar 2010 09:14:18 +0100

> 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…
[Chris] We had similar issues earlier in the MediaCtrl process that got 
a bit messy when we started adding stuff to MediaCtrl documents and have 
taken a wide berth since.  I think we will upset a few people by having 
it defined in the MRB doc - do the chairs agree in the new world of 
SIPCORE and DISPATCH?  I suspect to complete we do need an option tag - 
and I suspect it needs to be submitted to SIPCORE?  Eric/Spencer - thoughts?

Chris.

-- 
Chris Boulton
CTO & Co-founder
NS-Technologies <http://www.ns-technologies.com>
m: +44.7876.476681

---

From: Lorenzo Miniero <[email-masked]>
Date: Wed, 31 Mar 2010 10:31:56 +0200

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

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

---

From: Victor Paulsamy <[email-masked]>
Date: Wed, 31 Mar 2010 12:38:50 -0700

All,

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

--victor