Re: [MEDIACTRL] Questions on draft-ietf-mediactrl-ivr-control-package

[Scott McGlashan <[e-mail]>]

Hi Henry,

thanks for the comments and apologies for my delay in responding. 

The chairs are treating these as IETF Last Call Comments and after satisfactory resolution, we can move onto the next stage.

My response is marked as [SMCG]. For the WG, I've marked proposed spec changes with *** PROPOSED CHANGE. 

Let me know if you need further information or have an issue with a response.


Scott




On 8 Jan 2010, at 21:25, Henry Lum wrote:

> --_004_059AF07365DC474393A19A3AF187DF74051E1ACANAHALDusintgene_
> Content-Type: multipart/alternative;
> 	boundary="_000_059AF07365DC474393A19A3AF187DF74051E1ACANAHALDusintgene_"
> 
> --_000_059AF07365DC474393A19A3AF187DF74051E1ACANAHALDusintgene_
> Content-Type: text/plain; charset="Windows-1252"
> Content-Transfer-Encoding: quoted-printable
> 
> Hi,
> 
> This is the first time I have carefully read through the draft, and I have =
> a bunch of questions for the IVR control package:
> 
> 
> -          Why can=92t <dialogterminate> result in an <dialogexit> event fo=
> r PREPARED and STARTING state while this is done for STARTED state only? If=
> PREPARED state can generate dialogexit from a timeout, why can=92t it gene=
> rate a dialogexit from a dialogterminate?
> 

[SMCG]  The <dialogexit> is a notification event from MS to AS, i.e. it is not a response to an AS request. You're right that we could add a <dialogexit> payload to the 410 response when the AS terminates the dialog, but I'm not clear it adds anything to the current design. 


> -          Can the preparation duration for a prepared dialog be set in dia=
> logprepare? The recommended value of 30s seems to be fairly short to me, an=
> d CCXML does not have this kind of arbitrary timeout as well. If I am writi=
> ng an outbound calling application (with CCXML), I would first prepare the =
> dialog to make sure the dialog is ready to go (and making sure a VXML page =
> is well formed) and then I would place the outbound call. It=92s very likel=
> y by the time the user answers and call progress detection is completed, 30=
> s would have been passed and the prepared dialog would be terminated by thi=
> s timer. Why do we need this timeout anyways?
> 

[SMCG] The timeout was added because there was a group concern about tying up resources for an indefinite amount of time. I agree that 30s is probably too small and could be increased to 300s. 

**** PROPOSED CHANGE: Please let me know asap if anyone objects to increasing the recommended maximum dialog preparation duration from 30s to 300s. ***

 

> -          Section 4.2.2 =96 would it be more convenient that if neither co=
> nnectionid and conferenceid is defined, it would take the connection from t=
> he current SIP dialog associated with this control channel? Of course this =
> wouldn=92t work if the control channel is a dedicated one =96 I think it wo=
> uld be a syntactic sugar to have such a shortcut.
> 

[SMCG] Multiple user SIP dialogs can be controlled through the same control channel. So I'm not sure how your proposal would work.


> -          There is a typo in the example of section 4.2.2.1.1:
> 
> ...
>    <subscribe>
>     <dmtfnotify matchmode=3D"control"/>  -- should be dtmfsub instead
>    </subscribe>
> ...
> 

[SMCG] Good catch! Fixed in next version. 


> 
> -          Can a dialog prefetch all the media prompts inside the dialog an=
> d then report an error when any of the fetch fails? This is one thing I am =
> having problem with MSML is that you can only fail during execution and the=
> control client have to intelligently resume where the failure happens, thu=
> s adding complexity to the control client. If the control client knows one =
> of the prompts fail to fetch, it would be easier for the control client to =
> try an alternate prompt altogether rather than having the prompt to fail af=
> ter playing the fifth wav file.
> 

[SMCG] With a <dialogprepare> command, any fetch failures can be reported using a 409 error response code.  If the resource fails during executing, the MS sends a <dialogexit> with a 4 status. In both cases the MS can provide more detail on the error in the reason attribute. If you need automatic prompt fallback, then this capability is covered in the VoiceXML dialog type. 


> -          Am I allowed to define more than one <prompt> inside <dialog> so=
> that I can define the first <prompt> to be bargein=3Dfalse, and the second=
> one with bargin=3Dtrue? The execution model for <dialog> (#4 in 4.3.1) is =
> a bit unclear on this.
> 

[SMCG] The text says the <prompt> is optional, so maximum of one. XML schema in Section 5 is even clearer:

<xsd:element ref="prompt" minOccurs="0"
      maxOccurs="1" /

> -          The definition of <par> is a bit sketchy here. Should the child =
> elements of <par> target which <stream> it can target the output on? If the=
> re is no target, then how does MS know which stream it should place the out=
> put or the MS makes a best-effort decision on this?
> 


[SMCG] Right - it is the responsibility of the MS to map the <media> playback to the appropriate media streams. The package is agnostic to the mechanism used in the MS implementation. 


> -          If <control> is active for a <prompt>, does it mean bargein has =
> no effect for the <prompt>?
> 

[SMCG] Depends - bargein behavior is controlled by <prompt> and not <control>.. If the input matches an active control then prompt is terminated. If the input doesn't match an active control, then bargein depends on the attribute of the <prompt> element. 


> -          Does the DTMF digit buffer last over the lifetime of a <dialog>?
> 

[SMCG] The spec doesn't detail the lifetime of a digit buffer, [But I'd say, yes, at least the lifetime of a <dialog>; preferably the lifetime of the attached connection or conference otherwise the concept of clearing the buffer between dialog cycles is pretty weak.] 


> -          If I start two simultaneous <dialog> on a connection, then I ass=
> ume we send the DTMF digits to both dialogs, however, does media server kee=
> p a single digit buffer for both dialogs?
> 

[SMCG] Implementation issue on which the spec is (currently) agnostic. [But I'd associate the digit buffer with each connection/conference, and the buffer would be shared between multiple active dialogs.]  


> -          Does <control> automatically consume the entire digit buffer? Th=
> e third paragraph of 4.3.1.2 seems to imply this.

[SMCG] Not necessarily - <control>s match against the first DTMF in the buffer. If there are multiple DTMFs in the buffer, then only the consumed ones would be removed. I agree that 3rd paragraph of 4.3.1.2 should be clarified.

 *** PROPOSED CHANGE: Please let me know asap if anyone objects to replacing in 4.3.1.2: 

If incoming DTMF matches a specified runtime control, then the DTMF is not available to the <collect> operation, including its digit buffer.

with 

If an incoming DTMF character matches a specified runtime control, then the DTMF character is consumed: it is not added to digit buffer and so not available to the <collect> operation. 



> 
> -          If I am allowed to have multiple <prompt> elements, does <contro=
> l> take effect to all the <prompt> elements? Does that mean I can=92t just =
> use <control> on a <prompt> element and then not use it for the next <promp=
> t>?

[SMCG] This version doesn't support multiple <prompt> elements per <dialog>. 

> 
> -          In my opinion, I think a better way to express <control> is to a=
> llow a set of generic grammar to trigger events on <control>, which then se=
> nds a control action to a specified <prompt>, rather than having a prescrib=
> ed set of attributes that define both the event and the action. In a way a =
> <prompt> is an event-based element where it can take events sent from other=
> controls such as the <control> element. I think this is more in line with =
> the SMIL model as this spec is borrowing some parts of the event sequencing=
> with <par> and <seq> anyways. This can make extensions simpler if someone =
> wants to build a speech based control and send actions to a <prompt>.

[SMCG] I agree in theory. However, the event-based model can get complex. Characterizing <control> as grammars (allowing complex DTMF/ASR sequences) leads to some complex timing issues when <collect> is also active. I think that the current model is sufficient for the use cases - real time controls of prompt playback. But definitely a great topic for a later mediaCtrl package. 

> -          Just to be clear when <grammar> is defined in <collect>, does it=
> override escapekey, termchar, as well as maxdigits?

[SMCG] Not escapekey - it applies whether or not <grammar> is specified. But termchar and maxdigits only apply when a custom <grammar> is not specified. If you think we should clarify this more, please propose some wording changes (I think all the constraints are mentioned but clearer text is always good!). 

> 
> -          In the DTMF collection execution, noinput, nomatch, and match al=
> l results in a termination of collection execution. Does this imply that di=
> alog continue execution on step 5 of section 4.3.1?

[SMCG] Yes. 

> If the dialog defines a=
> repeatCount, then does it mean that the dialog repeats the collection agai=
> n?

[SMCG] Yes. 

> How do I model a different prompt for noinput and nomatch without having=
> the control client to request for a new dialog?

[SMCG] The <dialog> language doesn't support this feature (although you could use <media> src URI manipulation!). It has been discussed in the group and if I remember correctly VoiceXML dialogs were recommended if you want this feature within a single dialog cycle. 

> For a match, I can see tha=
> t I can use a dtmfnotify to notify the control client that a match is made,=
> but I still need the control client to explicitly terminate the dialog. I =
> worry that there are side effects with explicitly terminating the dialog on=
> a match when <dialogterminate> is processed slowly, the user may hear the =
> dialog again if the repeatCount is greater than one.
> 

[SMCG] Very much depends on your MS implementation. I don't remember any of the current implementations raising this as an issue, but I see your point. 


> -          I have a concern with <record> that I also have with MSCML and M=
> SML is that it allows record to specify a destination (loc attribute in <me=
> dia>). This in a way creates a bunch of related security issues that needs =
> to be addressed by the system and makes the markup inherently system-depend=
> ent. I actually like the way VXML defines it with a record item variable; y=
> ou can reuse it later in the markup and you can also submit it with the <su=
> bmit> tag. This makes the VXML implementation platform-independent and ther=
> e is no need to worry about security concerns inherited by exposing potenti=
> al system structure to the control client.

[SMCG] We've had an IETF security review and they didn't raise this issue. I understand the benefit  in vxml of being able to play a <record> variable directly, and that in both languages a URI is used to (a) locate the recording, or (b) locate the submission target. If your security concern is that the URI structure exposes system structure, then there are ways of addressing this (virtual URIs, let alone system authorization/security). Let me know if I've missed your point.  

> 
> -          Section 12.2.1 session.connection.redirect has an errata that I =
> also sent an email for RFC5552. It should take the History-Info hi-entry el=
> ements in order in the session variable.

[SMCG] I'm happy to make this change since our goal was to be aligned with RFC5552 on vxml mapping. Can you confirm that the RFC5552 errata has been accepted (e.g. are Mark and/or Dave ok with it)? 

** PROPOSED CHANGE: Please let me know asap if anyone objects to replacing in 12.2.1: 

session.connection.redirect
This array is populated by information contained in the History-Info ([RFC4244]) header in the initial INVITE or is otherwise undefined. Each entry (hi-entry) in the History-Info header is mapped, in reverse order, into an element of the session.connection.redirect array.

with 


session.connection.redirect
This array is populated by information contained in the History-Info ([RFC4244]) header in the initial INVITE or is otherwise undefined. Each entry (hi-entry) in the History-Info header is mapped, in the order it appeared in the History-Info header, into an element of the session.connection.redirect array.

> 
> -          When conferenceid attribute is used for a VXML dialog, will sess=
> ion.connection evaluate to null?

[SMCG] Evaluates to undefined. 

> 
> Sorry for inflicting a pile of questions =96 I plan to read up on the mixer=
> package and I=92ll probably have even more questions/comments :)

No apology necessary. It is great to know people read the spec at this level of detail, Henry. 


> 
> Thanks!
> Henry
> 
> 
> 
> 
> CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain conf=
> idential and proprietary information of Alcatel-Lucent and/or its affiliate=
> d entities. Access by the intended recipient only is authorized. Any liabil=
> ity arising from any party acting, or refraining from acting, on any inform=
> ation contained in this e-mail is hereby excluded. If you are not the inten=
> ded recipient, please notify the sender immediately, destroy the original t=
> ransmission and its attachments and do not disclose the contents to any oth=
> er person, use it for any purpose, or store or copy the information in any =
> medium. Copyright in this e-mail and any attachments belongs to Alcatel-Luc=
> ent and/or its affiliated entities.
> 
> --_000_059AF07365DC474393A19A3AF187DF74051E1ACANAHALDusintgene_
> Content-Type: text/html; charset="Windows-1252"
> Content-Transfer-Encoding: quoted-printable
> 
> <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
> osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
> xmlns:x=3D"urn:schemas-microsoft-com:office:excel" xmlns:p=3D"urn:schemas-m=
> icrosoft-com:office:powerpoint" xmlns:a=3D"urn:schemas-microsoft-com:office=
> :access" xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s=3D"=
> uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs=3D"urn:schemas-microsof=
> t-com:rowset" xmlns:z=3D"#RowsetSchema" xmlns:b=3D"urn:schemas-microsoft-co=
> m:office:publisher" xmlns:ss=3D"urn:schemas-microsoft-com:office:spreadshee=
> t" xmlns:c=3D"urn:schemas-microsoft-com:office:component:spreadsheet" xmlns=
> :odc=3D"urn:schemas-microsoft-com:office:odc" xmlns:oa=3D"urn:schemas-micro=
> soft-com:office:activation" xmlns:html=3D"http://www.w3.org/TR/REC-html40" =
> xmlns:q=3D"http://schemas.xmlsoap.org/soap/envelope/" xmlns:rtc=3D"http://m=
> icrosoft.com/officenet/conferencing" xmlns:D=3D"DAV:" xmlns:Repl=3D"http://=
> schemas.microsoft.com/repl/" xmlns:mt=3D"http://schemas.microsoft.com/share=
> point/soap/meetings/" xmlns:x2=3D"http://schemas.microsoft.com/office/excel=
> /2003/xml" xmlns:ppda=3D"http://www.passport.com/NameSpace.xsd" xmlns:ois=
> =3D"http://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir=3D"http://=
> schemas.microsoft.com/sharepoint/soap/directory/" xmlns:ds=3D"http://www.w3=
> .org/2000/09/xmldsig#" xmlns:dsp=3D"http://schemas.microsoft.com/sharepoint=
> /dsp" xmlns:udc=3D"http://schemas.microsoft.com/data/udc" xmlns:xsd=3D"http=
> ://www.w3.org/2001/XMLSchema" xmlns:sub=3D"http://schemas.microsoft.com/sha=
> repoint/soap/2002/1/alerts/" xmlns:ec=3D"http://www.w3.org/2001/04/xmlenc#"=
> xmlns:sp=3D"http://schemas.microsoft.com/sharepoint/" xmlns:sps=3D"http://=
> schemas.microsoft.com/sharepoint/soap/" xmlns:xsi=3D"http://www.w3.org/2001=
> /XMLSchema-instance" xmlns:udcs=3D"http://schemas.microsoft.com/data/udc/so=
> ap" xmlns:udcxf=3D"http://schemas.microsoft.com/data/udc/xmlfile" xmlns:udc=
> p2p=3D"http://schemas.microsoft.com/data/udc/parttopart" xmlns:wf=3D"http:/=
> /schemas.microsoft.com/sharepoint/soap/workflow/" xmlns:dsss=3D"http://sche=
> mas.microsoft.com/office/2006/digsig-setup" xmlns:dssi=3D"http://schemas.mi=
> crosoft.com/office/2006/digsig" xmlns:mdssi=3D"http://schemas.openxmlformat=
> s.org/package/2006/digital-signature" xmlns:mver=3D"http://schemas.openxmlf=
> ormats.org/markup-compatibility/2006" xmlns:m=3D"http://schemas.microsoft.c=
> om/office/2004/12/omml" xmlns:mrels=3D"http://schemas.openxmlformats.org/pa=
> ckage/2006/relationships" xmlns:spwp=3D"http://microsoft.com/sharepoint/web=
> partpages" xmlns:ex12t=3D"http://schemas.microsoft.com/exchange/services/20=
> 06/types" xmlns:ex12m=3D"http://schemas.microsoft.com/exchange/services/200=
> 6/messages" xmlns:pptsl=3D"http://schemas.microsoft.com/sharepoint/soap/Sli=
> deLibrary/" xmlns:spsl=3D"http://microsoft.com/webservices/SharePointPortal=
> Server/PublishedLinksService" xmlns:Z=3D"urn:schemas-microsoft-com:" xmlns:=
> st=3D"&#1;" xmlns=3D"http://www.w3.org/TR/REC-html40"><head>
> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3DWindows-1=
> 252">
> <meta name=3D"Generator" content=3D"Microsoft Word 12 (filtered medium)">
> <style>
> <!--
> /* Font Definitions */
> @font-face
> 	{font-family:Wingdings;
> 	panose-1:5 0 0 0 0 0 0 0 0 0;}
> @font-face
> 	{font-family:Wingdings;
> 	panose-1:5 0 0 0 0 0 0 0 0 0;}
> @font-face
> 	{font-family:Calibri;
> 	panose-1:2 15 5 2 2 2 4 3 2 4;}
> /* Style Definitions */
> p.MsoNormal, li.MsoNormal, div.MsoNormal
> 	{margin:0in;
> 	margin-bottom:.0001pt;
> 	font-size:11.0pt;
> 	font-family:"Calibri","sans-serif";}
> a:link, span.MsoHyperlink
> 	{mso-style-priority:99;
> 	color:blue;
> 	text-decoration:underline;}
> a:visited, span.MsoHyperlinkFollowed
> 	{mso-style-priority:99;
> 	color:purple;
> 	text-decoration:underline;}
> pre
> 	{mso-style-priority:99;
> 	mso-style-link:"HTML Preformatted Char";
> 	margin:0in;
> 	margin-bottom:.0001pt;
> 	font-size:10.0pt;
> 	font-family:"Courier New";}
> p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
> 	{mso-style-priority:34;
> 	margin-top:0in;
> 	margin-right:0in;
> 	margin-bottom:0in;
> 	margin-left:.5in;
> 	margin-bottom:.0001pt;
> 	font-size:11.0pt;
> 	font-family:"Calibri","sans-serif";}
> span.HTMLPreformattedChar
> 	{mso-style-name:"HTML Preformatted Char";
> 	mso-style-priority:99;
> 	mso-style-link:"HTML Preformatted";
> 	font-family:"Courier New";}
> span.EmailStyle20
> 	{mso-style-type:personal-compose;
> 	font-family:"Calibri","sans-serif";
> 	color:windowtext;
> 	font-weight:normal;
> 	font-style:normal;
> 	text-decoration:none none;}
> .MsoChpDefault
> 	{mso-style-type:export-only;
> 	font-size:10.0pt;}
> @page Section1
> 	{size:8.5in 11.0in;
> 	margin:1.0in 1.0in 1.0in 1.0in;}
> div.Section1
> 	{page:Section1;}
> /* List Definitions */
> @list l0
> 	{mso-list-id:2127846407;
> 	mso-list-type:hybrid;
> 	mso-list-template-ids:634840108 -1943750804 67698691 67698693 67698689 676=
> 98691 67698693 67698689 67698691 67698693;}
> @list l0:level1
> 	{mso-level-start-at:0;
> 	mso-level-number-format:bullet;
> 	mso-level-text:-;
> 	mso-level-tab-stop:none;
> 	mso-level-number-position:left;
> 	text-indent:-.25in;
> 	font-family:"Calibri","sans-serif";
> 	mso-fareast-font-family:Calibri;
> 	mso-bidi-font-family:"Times New Roman";}
> @list l0:level2
> 	{mso-level-tab-stop:1.0in;
> 	mso-level-number-position:left;
> 	text-indent:-.25in;}
> @list l0:level3
> 	{mso-level-tab-stop:1.5in;
> 	mso-level-number-position:left;
> 	text-indent:-.25in;}
> @list l0:level4
> 	{mso-level-tab-stop:2.0in;
> 	mso-level-number-position:left;
> 	text-indent:-.25in;}
> @list l0:level5
> 	{mso-level-tab-stop:2.5in;
> 	mso-level-number-position:left;
> 	text-indent:-.25in;}
> @list l0:level6
> 	{mso-level-tab-stop:3.0in;
> 	mso-level-number-position:left;
> 	text-indent:-.25in;}
> @list l0:level7
> 	{mso-level-tab-stop:3.5in;
> 	mso-level-number-position:left;
> 	text-indent:-.25in;}
> @list l0:level8
> 	{mso-level-tab-stop:4.0in;
> 	mso-level-number-position:left;
> 	text-indent:-.25in;}
> @list l0:level9
> 	{mso-level-tab-stop:4.5in;
> 	mso-level-number-position:left;
> 	text-indent:-.25in;}
> ol
> 	{margin-bottom:0in;}
> ul
> 	{margin-bottom:0in;}
> -->
> </style>
> <!--[if gte mso 9]><xml>
> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
> </xml><![endif]--><!--[if gte mso 9]><xml>
> <o:shapelayout v:ext=3D"edit">
>  <o:idmap v:ext=3D"edit" data=3D"1" />
> </o:shapelayout></xml><![endif]-->
> </head>
> 
> <body lang=3D"EN-US" link=3D"blue" vlink=3D"purple">
> 
> <div class=3D"Section1">
> 
> <p class=3D"MsoNormal">Hi,<o:p></o:p></p>
> 
> <p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
> 
> <p class=3D"MsoNormal">This is the first time I have carefully read through=
> the
> draft, and I have a bunch of questions for the IVR control package:<o:p></o=
> :p></p>
> 
> <p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
> 
> <p class=3D"MsoListParagraph" style=3D"text-indent:-.25in;mso-list:l0 level=
> 1 lfo2"><![if !supportLists]><span style=3D"mso-list:Ignore">-<span style=
> =3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
> nbsp;&nbsp;&nbsp;&nbsp;
> </span></span><![endif]>Why can=92t &lt;dialogterminate&gt; result in an
> &lt;dialogexit&gt; event for PREPARED and STARTING state while this is done=
> for
> STARTED state only? If PREPARED state can generate dialogexit from a timeou=
> t,
> why can=92t it generate a dialogexit from a dialogterminate?<o:p></o:p></p>
> 
> <p class=3D"MsoListParagraph" style=3D"text-indent:-.25in;mso-list:l0 level=
> 1 lfo2"><![if !supportLists]><span style=3D"mso-list:Ignore">-<span style=
> =3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
> nbsp;&nbsp;&nbsp;&nbsp;
> </span></span><![endif]>Can the preparation duration for a prepared dialog =
> be
> set in dialogprepare? The recommended value of 30s seems to be fairly short=
> to
> me, and CCXML does not have this kind of arbitrary timeout as well. If I am
> writing an outbound calling application (with CCXML), I would first prepare=
> the
> dialog to make sure the dialog is ready to go (and making sure a VXML page =
> is
> well formed) and then I would place the outbound call. It=92s very likely
> by the time the user answers and call progress detection is completed, 30s
> would have been passed and the prepared dialog would be terminated by this
> timer. Why do we need this timeout anyways?<o:p></o:p></p>
> 
> <p class=3D"MsoListParagraph" style=3D"text-indent:-.25in;mso-list:l0 level=
> 1 lfo2"><![if !supportLists]><span style=3D"mso-list:Ignore">-<span style=
> =3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
> nbsp;&nbsp;&nbsp;&nbsp;
> </span></span><![endif]>Section 4.2.2 =96 would it be more convenient that
> if neither connectionid and conferenceid is defined, it would take the
> connection from the current SIP dialog associated with this control channel=
> ? Of
> course this wouldn=92t work if the control channel is a dedicated one
> =96 I think it would be a syntactic sugar to have such a shortcut.<o:p></o:=
> p></p>
> 
> <p class=3D"MsoListParagraph" style=3D"text-indent:-.25in;mso-list:l0 level=
> 1 lfo2"><![if !supportLists]><span style=3D"mso-list:Ignore">-<span style=
> =3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
> nbsp;&nbsp;&nbsp;&nbsp;
> </span></span><![endif]>There is a typo in the example of section 4.2.2.1.1=
> :<o:p></o:p></p>
> 
> <p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
> 
> <p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
> urier New&quot;">...<o:p></o:p></span></p>
> 
> <p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
> urier New&quot;">&nbsp;&nbsp;&nbsp;
> &lt;subscribe&gt;<o:p></o:p></span></p>
> 
> <p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Co=
> urier New&quot;">&nbsp;&nbsp;&nbsp;&nbsp;
> &lt;dmtfnot