Re: [MEDIACTRL] WGLC: Call Flows

[Robert Sparks <[e-mail]>]

inline -

On 12/3/12 5:00 PM, Lorenzo Miniero wrote:
> On Mon, 03 Dec 2012 14:33:25 -0600
> Robert Sparks <[e-mail]> wrote:
>
>> On 12/3/12 8:45 AM, Eric Burger wrote:
>>> We are almost finished! One last document to go, the Media Control Channel Framework (CFW) Call Flow Examples.  You can pickup a copy here:
>>> https://datatracker.ietf.org/doc/draft-ietf-mediactrl-call-flows
>>>
>>> Please review CLOSELY, as no matter how many times we tell implementors to read the base specifications and that this document is simply a non-normtive example,  implementors will blindly copy from this document and not read the base documents. It MUST be as accurate as possible.
>>>
>>> Because of the importance of getting this right, the Work Group Last Call will run until 21 December 2012.
>> Yes, please. If you are going to dive deep on any one particular aspect
>> of this review, please let the list know so
>> we spread the effort around. There's a _lot_ to review here.
>>
>> Lorenzo - I really appreciate that the SIP was generated by real
>> implementations - did you set things up where they were actually using
>> example.com and example.net or did you edit the captured messages to say
>> that after the fact?
>>
>
> Those messages were edited, as they originally involved the local environment we deployed our testbed in. I tried to make sure the content lengths were properly adjusted where necessary, though.
That helps, thanks. Reviews should look at the places those names occur 
and make sure the right ones landed in the right places.
>
>
>> One question about some of the CFW examples. We have this section:
>>
>> 2.  Conventions
>>
>>      Note that due to RFC formatting conventions, this document often
>>      splits SIP/SDP and CFW across lines whose content would exceed 72
>>      characters.  A backslash character marks where this line folding has
>>      taken place.  This backslash and its trailing CRLF and whitespace
>>      would not appear in the actual protocol contents.  Besides, also note
>>      that the indentation of the XML content is only provided for
>>      readability: actual messages will follow strict XML syntax, which
>>      allows for, but does not require, indentation.  Due to the same 72
>>      characters limitation, this document also sometimes splits the
>>      content of XML elements across lines: please beware that, when this
>>      happens, no whitespace is actually meant to be neither at the
>>      beginning nor at the end of the element content.
>>
>> Should it go on to say that the Content-Lengths in the examples were
>> calculated _before_ formatting the example for publication in the RFC?
>> I can't, for example, make the content-length in this example make sense:
>>
>> D1. AS <- MS (CFW CONTROL event, dtmfnotify)
>> --------------------------------------------
>>      CFW 361840da0581 CONTROL
>>      Control-Package: msc-ivr/1.0
>>      Content-Type: application/msc-ivr+xml
>>      Content-Length: 179
>>
>>      <mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
>>         <event dialogid="3e936e0">
>>            <dtmfnotify matchmode="control" dtmf="6"
>>                        timestamp="2008-12-16T12:58:36Z"/>
>>         </event>
>>      </mscivr>
>>
>> Even if I rip out _all_ the whitespace outside of the tags and assume
>> a single LF instead of a CRLF, I get 180?
>>
>> 0000000   <   m   s   c   i   v   r       v   e   r   s   i   o n   =
>> 0000010   "   1   .   0   "       x   m   l   n   s   =   "   u r   n
>> 0000020   :   i   e   t   f   :   p   a   r   a   m   s   :   x m   l
>> 0000030   :   n   s   :   m   s   c   -   i   v   r   "   > <   e   v
>> 0000040   e   n   t       d   i   a   l   o   g   i   d   =   " 3   e
>> 0000050   9   3   6   e   0   "   >   <   d   t   m   f   n o   t   i
>> 0000060   f   y       m   a   t   c   h   m   o   d   e   =   " c   o
>> 0000070   n   t   r   o   l   "       d   t   m   f   =   "   6 "
>> 0000080   t   i   m   e   s   t   a   m   p   =   "   2   0   0 8   -
>> 0000090   1   2   -   1   6   T   1   2   :   5   8   :   3   6 Z   "
>> 00000a0   /   >   <   /   e   v   e   n   t   >   < /   m   s   c   i
>> 00000b0   v   r   >  \n
>>
>
> Just as with SIP, we tried to keep the content length consistent when the payload was edited (e.g., in small changes in the protocol that didn't really need a new dump). With respect to the example you reported, the payload in our prototype does not include the trailing LF either, but just the XML content, so I guess that's where the extra character in the count comes from.
That would be it. The type application/msc-ivr+xml doesn't require the 
trailing newline does it?
>
> Lorenzo
>
>
>> RjS
>>
>>
>>
>>> _______________________________________________
>>> MEDIACTRL mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/mediactrl
>>> Supplemental Web Site:
>>> http://www.standardstrack.com/ietf/mediactrl
>