Subject: Re: [siprec] Barry Leiba's Discuss on draft-ietf-siprec-protocol-16: (with DISCUSS and COMMENT)

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Fri, 25 Sep 2015 21:19:35 +0000

Thanks Ram. I have incorporated these changes into version 18, which I
will post soon.

Cheers,
Charles

On 8/8/15, 7:47 AM, "Ram Mohan R (rmohanr)" <[email-masked]> wrote:

>Hi Charles/All,
>
>Attached is the updated Metadata draft that I intend to publish once I get
>feedback from WG. It has the changes (section 7) and schema changes to
>accommodate the formal syntax for requesting Snapshot. There are other
>changes in the diff that address Yaron’s comments on the XML examples that
>he found during his implementation. Refer to thread here -
>http://www.ietf.org/mail-archive/web/siprec/current/msg04183.html
>
>IMO you can update the Protocol draft section 9.2 example to have the
>following. Also the text content-type has to change to use the same
>content-type application/rs-metadata instead of a new one that the current
>draft has.
>
>UPDATE sip:[email-masked] SIP/2.0
>Via: SIP/2.0/UDP srs.example.com;branch=z9hG4bKdf6b622b648d9
>To: <sip:[email-masked]>;tag=35e195d2-947d-4585-946f-098392474
>From: <sip:[email-masked]>;tag=1234567890
>Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a
>CSeq: 1 UPDATE
>Max-Forwards: 70
>Require: siprec
>Contact: <sip:[email-masked]>;+sip.srs
>Accept: application/sdp, application/rs-metadata
>Content-Disposition: recording-session
>Content-Type: application/rs-metadata
>Content-Length: 196
>
>
><?xml version="1.0" encoding="UTF-8"?>
>  <requestsnapshot xmlns='urn:ietf:params:xml:ns:recording:1'>
>     <requestreason xml:lang="it”>SRS internal error</requestreason>
>  </requestsnapshot>
>
>
>I will also add  SRS requesting snapshot example to Call flows draft as
>well as all the other examples are in that document.
>
>
>
>Ram
>
>-----Original Message-----
>From: "Charles Eckel (eckelcu)" <[email-masked]>
>Date: Saturday, 8 August 2015 12:53 am
>To: Paul Kyzivat <[email-masked]>, Cisco Employee
><[email-masked]>, Yaron Pdut <[email-masked]>, Andrew Hutton
><[email-masked]>, "[email-masked]" <[email-masked]>
>Subject: Re: [siprec] Barry Leiba's Discuss on
>draft-ietf-siprec-protocol-16: (with DISCUSS and COMMENT)
>
>>For the protocol draft, this change results in replacing
>>rs-metadata-request with rs-metadata, replacing section 9.2.1 "Formal
>>Syntax" with a reference to the metadata draft, and removing section 11.4
>>“Media Type Registration". Does that sound right?
>>
>>Cheers,
>>Charles
>>
>>On 8/5/15, 9:51 AM, "siprec on behalf of Paul Kyzivat"
>><[email-masked] on behalf of [email-masked]> wrote:
>>
>>>Ram,
>>>
>>>This looks good to me. It is what I had in mind, with all the messy
>>>details worked out.
>>>
>>>	Thanks,
>>>	Paul
>>>
>>>On 8/4/15 12:57 PM, Ram Mohan R (rmohanr) wrote:
>>>> HI Paul,
>>>> 
>>>> I just checked with few folks and also looked around recent RFCs.
>>>>There
>>>> are specifications like https://tools.ietf.org/html/rfc7395#appendix-A
>>>> that already uses
>>>> Multiple top level elements with same XML namespace. I also see in
>>>>RFC7395
>>>> example instances that allow to use top elements with same namespace.
>>>> 
>>>> So it is technically feasible.
>>>> 
>>>> So here is the updated schema (pasted only snippets). I will send the
>>>> updated draft by adding this along with few other comments I have
>>>>received
>>>> on metadata draft.
>>>> 
>>>> Along the top level recording element I will another element as below:
>>>> 
>>>> <xs:element name="recording" type="tns:recording”/>
>>>> <xs:element name="requestsnapshot" type="tns:requestsnapshot"/>
>>>> 
>>>> The newly added element will have schema as below:
>>>> 
>>>> 
>>>> <xs:complexType name="requestsnapshot">
>>>>   <xs:sequence>
>>>>    <xs:element name="requestreason" type="tns:name"  minOccurs="0"/>
>>>>    <xs:any namespace='##other'
>>>>         minOccurs='0'
>>>>         maxOccurs='unbounded'
>>>>         processContents='lax'/>
>>>>   </xs:sequence>
>>>>       </xs:complexType>
>>>> 
>>>> 
>>>> 
>>>> An example of snapshot request would look like below:
>>>> 
>>>> 
>>>> UPDATE sip:[email-masked] SIP/2.0
>>>>             Via: SIP/2.0/UDP
>>>> srs.example.com;branch=z9hG4bKdf6b622b648d9
>>>>             To:
>>>> <sip:[email-masked]>;tag=35e195d2-947d-4585-946f-098392474
>>>>             From: <sip:[email-masked]>;tag=1234567890
>>>>             Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a
>>>>             CSeq: 1 UPDATE
>>>>             Max-Forwards: 70
>>>>             Require: siprec
>>>>             Contact: <sip:[email-masked]>;+sip.srs
>>>>             Accept: application/sdp, application/rs-metadata
>>>>             Content-Disposition: recording-session
>>>>             Content-Type: application/rs-metadata
>>>>             Content-Length: [length]
>>>> 
>>>>       
>>>> <?xml version="1.0" encoding="UTF-8"?>
>>>>         <requestsnapshot xmlns='urn:ietf:params:xml:ns:recording:1'>
>>>>     <requestreason xml:lang="it”>SRS internal error</requestreason>
>>>>          </requestsnapshot>
>>>> 
>>>> If some one has better names for the elements please suggest.
>>>> 
>>>> 
>>>> 
>>>> 
>>>> Regards,
>>>> Ram
>>>> 
>>>> -----Original Message-----
>>>> From: Cisco Employee <[email-masked]>
>>>> Date: Friday, 24 July 2015 8:27 pm
>>>> To: Paul Kyzivat <[email-masked]>, Yaron Pdut
>>>> <[email-masked]>, Andrew Hutton <[email-masked]>,
>>>> "[email-masked]" <[email-masked]>
>>>> Subject: Re: [siprec] Barry Leiba's Discuss on
>>>> draft-ietf-siprec-protocol-16: (with DISCUSS and COMMENT)
>>>> 
>>>>> Ok I get your point. I will check if its possible to have two top
>>>>>level
>>>>> elements with same namespace. If that is not feasible then we have to
>>>>> re-visit this.
>>>>> I am not so keen on adding a new namespace just for this one element.
>>>>>
>>>>> Ram
>>>>>
>>>>> -----Original Message-----
>>>>> From: Paul Kyzivat <[email-masked]>
>>>>> Date: Friday, 24 July 2015 12:46 pm
>>>>> To: Cisco Employee <[email-masked]>, Yaron Pdut
>>>>><[email-masked]>,
>>>>> Andrew Hutton <[email-masked]>, "[email-masked]"
>>>>> <[email-masked]>
>>>>> Subject: Re: [siprec] Barry Leiba's Discuss on
>>>>> draft-ietf-siprec-protocol-16: (with DISCUSS and COMMENT)
>>>>>
>>>>>> On 7/24/15 5:51 AM, Ram Mohan R (rmohanr) wrote:
>>>>>>> Ok. I will check with some XML experts I know of.
>>>>>>> OTOH Do you see any issues with this being child element of
>>>>>>><recording>
>>>>>>> element. In that way it can be inline with other XML elements.
>>>>>>>
>>>>>>> Is there a reason you this to be a top element ?
>>>>>>
>>>>>> Right now, <recording> is a complex type containing a sequence of
>>>>>>stuff.
>>>>>>
>>>>>> If this new element is to be within <recording> then the definition
>>>>>>of
>>>>>> <recording>  must change. It must be a choice. One leg of the choice
>>>>>> would be the sequence of stuff used from SRC to SRS. The other leg
>>>>>>of
>>>>>> the choice would be the stuff used from SRS to SRC.
>>>>>>
>>>>>> That would *work*, but IMO it is ugly and rather unclear. If we
>>>>>>wanted
>>>>>> to clean it up, while retaining <recording> as the universal top
>>>>>>level
>>>>>> element, then I think we would add another layer of element. For
>>>>>> instance <recording> might have two alternative sub-elements:
>>>>>><snapshot>
>>>>>> and <snapshotRequest>. (Then <snapshot> could also subsume the
>>>>>>purpose
>>>>>> of <datamode>.)
>>>>>>
>>>>>> But that would be be a significantly incompatible change.
>>>>>>
>>>>>> Elevating the snapshot request to be a peer of recording
>>>>>>accomplishes
>>>>>> the same end a different way.
>>>>>>
>>>>>> But I'm not sure if it is valid to define a content-type as being
>>>>>>one
>>>>>>of
>>>>>> two different elements of a schema.
>>>>>>
>>>>>> 	Thanks,
>>>>>> 	Paul
>>>>>>
>>>>>>> Ram
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Paul Kyzivat <[email-masked]>
>>>>>>> Date: Thursday, 23 July 2015 11:25 pm
>>>>>>> To: Cisco Employee <[email-masked]>, Yaron Pdut
>>>>>>> <[email-masked]>,
>>>>>>> Andrew Hutton <[email-masked]>, "[email-masked]"
>>>>>>> <[email-masked]>
>>>>>>> Subject: Re: [siprec] Barry Leiba's Discuss on
>>>>>>> draft-ietf-siprec-protocol-16: (with DISCUSS and COMMENT)
>>>>>>>
>>>>>>>> I defer to somebody with more knowledge of xml than I have.
>>>>>>>>
>>>>>>>> 	Thanks,
>>>>>>>> 	Paul
>>>>>>>>
>>>>>>>> On 7/23/15 1:29 PM, Ram Mohan R (rmohanr) wrote:
>>>>>>>>> There is no strong reason for this.  Currently all the XML
>>>>>>>>>elements
>>>>>>>>> are
>>>>>>>>> with in <recording> with that being a top element having the name
>>>>>>>>> space
>>>>>>>>> as
>>>>>>>>> attribute and I just followed that.
>>>>>>>>> It is fine to have <reqsnapshot> as another top element. But if
>>>>>>>>>we
>>>>>>>>>do
>>>>>>>>> that
>>>>>>>>> way can we still use same namespace ?
>>>>>>>>>
>>>>>>>>> Also I was thinking a bit and I think the name of the element
>>>>>>>>>should
>>>>>>>>> be
>>>>>>>>> <reqsnapshot> with all small letters as that is the naming
>>>>>>>>>convention
>>>>>>>>> we
>>>>>>>>> have used for every other element.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Ram
>>>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: Paul Kyzivat <[email-masked]>
>>>>>>>>> Date: Thursday, 23 July 2015 5:56 pm
>>>>>>>>> To: Cisco Employee <[email-masked]>, Yaron Pdut
>>>>>>>>> <[email-masked]>,
>>>>>>>>> Andrew Hutton <[email-masked]>, "[email-masked]"
>>>>>>>>> <[email-masked]>
>>>>>>>>> Subject: Re: [siprec] Barry Leiba's Discuss on
>>>>>>>>> draft-ietf-siprec-protocol-16: (with DISCUSS and COMMENT)
>>>>>>>>>
>>>>>>>>>> Ram,
>>>>>>>>>>
>>>>>>>>>> I see you have <reqSnapshot> within a <recording> element.
>>>>>>>>>> Is there any reason for that? ISTM that it could be another top
>>>>>>>>>> level
>>>>>>>>>> element.
>>>>>>>>>>
>>>>>>>>>> 	Thanks,
>>>>>>>>>> 	Paul
>>>>>>>>>>
>>>>>>>>>> On 7/23/15 11:27 AM, Ram Mohan R (rmohanr) wrote:
>>>>>>>>>>> Hi All,
>>>>>>>>>>>
>>>>>>>>>>> We had a side discussion in the IETF and here is the proposal
>>>>>>>>>>>for
>>>>>>>>>>> SRS
>>>>>>>>>>> to
>>>>>>>>>>> send request to SRC for metadata snapshot.
>>>>>>>>>>>      This would take care of Barry’s concerns as we have a
>>>>>>>>>>>formal
>>>>>>>>>>> syntax
>>>>>>>>>>> and
>>>>>>>>>>> also this allows for extensibility in future.
>>>>>>>>>>>
>>>>>>>>>>> Let me know your comments/concerns. I will incorporate this in
>>>>>>>>>>>to
>>>>>>>>>>> Metadata
>>>>>>>>>>> and publish a new revision.
>>>>>>>>>>>
>>>>>>>>>>> 1)We will use the same Content-Type “application/rs-metadata”
>>>>>>>>>>>with
>>>>>>>>>>> just
>>>>>>>>>>> adding a new XML element inside the Metadata XML namespace.
>>>>>>>>>>>
>>>>>>>>>>>      
>>>>>>>>>>> An example of how snapshot can be requested in UPDATE message
>>>>>>>>>>>is
>>>>>>>>>>> shown
>>>>>>>>>>> below:
>>>>>>>>>>>
>>>>>>>>>>> A snapshot request for metadata from SRS to SRC would look as:
>>>>>>>>>>> UPDATE sip:[email-masked] SIP/2.0
>>>>>>>>>>>            Via: SIP/2.0/UDP
>>>>>>>>>>> srs.example.com;branch=z9hG4bKdf6b622b648d9
>>>>>>>>>>>            To:
>>>>>>>>>>> <sip:[email-masked]>;tag=35e195d2-947d-4585-946f-098392474
>>>>>>>>>>>            From: <sip:[email-masked]>;tag=1234567890
>>>>>>>>>>>            Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a
>>>>>>>>>>>            CSeq: 1 UPDATE
>>>>>>>>>>>            Max-Forwards: 70
>>>>>>>>>>>            Require: siprec
>>>>>>>>>>>            Contact: <sip:[email-masked]>;+sip.srs
>>>>>>>>>>>            Accept: application/sdp, application/rs-metadata
>>>>>>>>>>>            Content-Disposition: recording-session
>>>>>>>>>>>            Content-Type: application/rs-metadata
>>>>>>>>>>>            Content-Length: [length]
>>>>>>>>>>>
>>>>>>>>>>>      
>>>>>>>>>>> <?xml version="1.0" encoding="UTF-8"?>
>>>>>>>>>>>        <recording xmlns='urn:ietf:params:xml:ns:recording:1'>
>>>>>>>>>>>         <reqSnapshot>
>>>>>>>>>>>              <reason xml:lang="it”>SRS internal error</reason>
>>>>>>>>>>>         </requestSnapshot>
>>>>>>>>>>>            </recording>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Here is the  Schema for the new XML element. This will be added
>>>>>>>>>>> inside
>>>>>>>>>>> <recording> element in the Schema.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>      <xs:complexType name=“reqSnapshot">
>>>>>>>>>>>
>>>>>>>>>>>       <xs:sequence>
>>>>>>>>>>>           <xs:element name=“reason" type=“tns:name"
>>>>>>>>>>>             minOccurs="0"/>
>>>>>>>>>>>          <xs:any namespace='##other'
>>>>>>>>>>>            minOccurs='0'
>>>>>>>>>>>            maxOccurs='unbounded'
>>>>>>>>>>>            processContents='lax'/>
>>>>>>>>>>>       </xs:sequence>
>>>>>>>>>>>          </xs:complexType>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> The type of reason XML element is tns:name. “name” is already
>>>>>>>>>>> defined
>>>>>>>>>>> in
>>>>>>>>>>> the schema to be xs:string of alphanumeric characters.
>>>>>>>>>>>
>>>>>>>>>>> Regards,
>>>>>>>>>>> Ram
>>>>>>>>>>>
>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>> From: Cisco Employee <[email-masked]>
>>>>>>>>>>> Date: Thursday, 2 July 2015 6:20 am
>>>>>>>>>>> To: Yaron Pdut <[email-masked]>, Andrew Hutton
>>>>>>>>>>> <[email-masked]>, Paul Kyzivat
>>>>>>>>>>><[email-masked]>,
>>>>>>>>>>> "[email-masked]" <[email-masked]>
>>>>>>>>>>> Subject: Re: [siprec] Barry Leiba's Discuss on
>>>>>>>>>>> draft-ietf-siprec-protocol-16: (with DISCUSS and COMMENT)
>>>>>>>>>>>
>>>>>>>>>>>> Yaron,
>>>>>>>>>>>>
>>>>>>>>>>>> Agree on your concerns. But we need to have a way to address
>>>>>>>>>>>>the
>>>>>>>>>>>> comments
>>>>>>>>>>>> from
>>>>>>>>>>>> Barry Leiba to move this ahead. Barry’s concern is w.r.t using
>>>>>>>>>>>> free
>>>>>>>>>>>> flowing text in the request for metadata from SRS to SRC.
>>>>>>>>>>>>
>>>>>>>>>>>> There are two options as I see on the table right now.
>>>>>>>>>>>> 1) Pauls Proposal to use the same C-T
>>>>>>>>>>>>(application/rs-metadata),
>>>>>>>>>>>> have a
>>>>>>>>>>>> snew element in the XML NS that indicates its a request for
>>>>>>>>>>>> snapshot.
>>>>>>>>>>>> Some
>>>>>>>>>>>> thing like <request>
>>>>>>>>>>>> 2) Have a different C-T (application/rs-metadata-request), and
>>>>>>>>>>>> have a
>>>>>>>>>>>> XML
>>>>>>>>>>>> element that indicates request for snapshot
>>>>>>>>>>>>
>>>>>>>>>>>> 1 is probably simpler. Do you have any other suggestions on
>>>>>>>>>>>>how
>>>>>>>>>>>>we
>>>>>>>>>>>> can
>>>>>>>>>>>> request for metadata from SRS to SRC with minimal changes to
>>>>>>>>>>>>the
>>>>>>>>>>>> protocol
>>>>>>>>>>>> ?
>>>>>>>>>>>>
>>>>>>>>>>>> Regards,
>>>>>>>>>>>> Ram
>>>>>>>>>>>>
>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>> From: Yaron Pdut <[email-masked]>
>>>>>>>>>>>> Date: Monday, 22 June 2015 11:59 pm
>>>>>>>>>>>> To: Cisco Employee <[email-masked]>, Andrew Hutton
>>>>>>>>>>>> <[email-masked]>, Paul Kyzivat
>>>>>>>>>>>><[email-masked]>,
>>>>>>>>>>>> "[email-masked]" <[email-masked]>
>>>>>>>>>>>> Subject: Re: [siprec] Barry Leiba's Discuss on
>>>>>>>>>>>> draft-ietf-siprec-protocol-16: (with DISCUSS and COMMENT)
>>>>>>>>>>>>
>>>>>>>>>>>>> Trying to be pragmatic, today there are dozens of SIPREC
>>>>>>>>>>>>> implementations
>>>>>>>>>>>>> in the market that support the current specification for few
>>>>>>>>>>>>> years
>>>>>>>>>>>>> now, I
>>>>>>>>>>>>> do not see them modifing code at this stage.
>>>>>>>>>>>>>
>>>>>>>>>>>>> This means that the RFC will be a dead word for most vendors
>>>>>>>>>>>>>on
>>>>>>>>>>>>> one
>>>>>>>>>>>>> hand
>>>>>>>>>>>>> and will force SRS vendors to support yet another version (we
>>>>>>>>>>>>> already
>>>>>>>>>>>>> support at least 3 flavors of it today) on the other hand.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Already today there are many voices in industry thinking
>>>>>>>>>>>>>SIPREC
>>>>>>>>>>>>> intrudoce
>>>>>>>>>>>>> too much overhead. It is too open, too complex protocol, and
>>>>>>>>>>>>>they
>>>>>>>>>>>>> are
>>>>>>>>>>>>> considering lightweight REST based API as an alternative.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Approving this, IMHO, will put SIPREC future in a question.
>>>>>>>>>>>>>
>>>>>>>>>>>>> BR,
>>>>>>>>>>>>> Yaron
>>>>>>>>>>>>>
>>>>>>>>>>>>> -------- Original Message --------
>>>>>>>>>>>>> From: "Ram Mohan R (rmohanr)" <[email-masked]>
>>>>>>>>>>>>> Date: Mon, June 22, 2015 6:42 PM +0300
>>>>>>>>>>>>> To: "Hutton, Andrew" <[email-masked]>, Paul Kyzivat
>>>>>>>>>>>>> <[email-masked]>, [email-masked]
>>>>>>>>>>>>> Subject: Re: [siprec] Barry Leiba's Discuss on
>>>>>>>>>>>>> draft-ietf-siprec-protocol-16: (with DISCUSS and COMMENT)
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>> From: <Hutton>, Andrew <[email-masked]>
>>>>>>>>>>>>> Date: Monday, 22 June 2015 8:43 pm
>>>>>>>>>>>>> To: Cisco Employee <[email-masked]>, Paul Kyzivat
>>>>>>>>>>>>> <[email-masked]>, "[email-masked]" <[email-masked]>
>>>>>>>>>>>>> Subject: RE: [siprec] Barry Leiba's Discuss on
>>>>>>>>>>>>> draft-ietf-siprec-protocol-16: (with DISCUSS and COMMENT)
>>>>>>>>>>>>>
>>>>>>>>>>>>>> ON: 19 June 2015 00:46 Ram Mohan R Wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I have a question - is it allowed to have a two different
>>>>>>>>>>>>>>>C-T
>>>>>>>>>>>>>>> (say
>>>>>>>>>>>>>>> "application/rs-metadata-request" and
>>>>>>>>>>>>>>> "application/rs-metadata")
>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>> still
>>>>>>>>>>>>>>> have content point to same XML document ?
>>>>>>>>>>>>>>> The reason for asking is I still feel they have to be
>>>>>>>>>>>>>>>different
>>>>>>>>>>>>>>> C-T
>>>>>>>>>>>>>>> as
>>>>>>>>>>>>>>> they are not related. One C-T is for representing the
>>>>>>>>>>>>>>>snapshot
>>>>>>>>>>>>>>> of
>>>>>>>>>>>>>>> metadata
>>>>>>>>>>>>>>> and other is for requesting the same. So logically it make
>>>>>>>>>>>>>>> sense
>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>> still
>>>>>>>>>>>>>>> consider them as two different content-types. The C-D can
>>>>>>>>>>>>>>>be
>>>>>>>>>>>>>>> same
>>>>>>>>>>>>>>> as
>>>>>>>>>>>>>>> both
>>>>>>>>>>>>>>> are for recording session.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I don't think they have to be different C-T's that surely
>>>>>>>>>>>>>> depends
>>>>>>>>>>>>>> on
>>>>>>>>>>>>>> how
>>>>>>>>>>>>>> the XML content is defined.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Sure.
>>>>>>>>>>>>>
>>>>>>>>>>>>> As I mentioned I don¹t see any real advantage in having same
>>>>>>>>>>>>>C-T
>>>>>>>>>>>>> vs
>>>>>>>>>>>>> different one.  OTOH by having same C-T for metadata req and
>>>>>>>>>>>>> metadata, an
>>>>>>>>>>>>> SRC now has to parse the entire XML to understand what the
>>>>>>>>>>>>>SRS
>>>>>>>>>>>>> wants
>>>>>>>>>>>>> before replying to the RE-INVITE/UPDATE it got from SRS. By
>>>>>>>>>>>>> having a
>>>>>>>>>>>>> different C-T by an SRC can act by looking at the C-T header
>>>>>>>>>>>>> value
>>>>>>>>>>>>> itself
>>>>>>>>>>>>> and optionally choose to parse XML.  If that is some thing
>>>>>>>>>>>>>the
>>>>>>>>>>>>>WG
>>>>>>>>>>>>> is
>>>>>>>>>>>>> ok
>>>>>>>>>>>>> with I am fine as well.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I will come up with the XML syntax for the request on the
>>>>>>>>>>>>> suggestion
>>>>>>>>>>>>> from
>>>>>>>>>>>>> Paul and send the updated schema to the list.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>> Ram
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Andy
>>>>>>>>>>>>>
>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>> siprec mailing list
>>>>>>>>>>>>> [email-masked]
>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/siprec
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>> 
>>>
>>>_______________________________________________
>>>siprec mailing list
>>>[email-masked]
>>>https://www.ietf.org/mailman/listinfo/siprec
>>
>

---

From: Alissa Cooper <[email-masked]>
Date: Fri, 25 Sep 2015 15:42:27 -0700

Barry, have a look at the -18 and see if this resolves your DISCUSS.

Thanks,
Alissa

> On May 27, 2015, at 1:10 PM, Barry Leiba <[email-masked]> wrote:
> 
> Barry Leiba has entered the following ballot position for
> draft-ietf-siprec-protocol-16: Discuss
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-siprec-protocol/
> 
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> I have to raise one of Ben's comments to DISCUSS, after giving it a lot
> of thought.  We talked about it before Ben posted his ballot, and I said
> that I thought the way the rs-metadata-request subtype is used is abusing
> media types: media types are meant to label containers for protocol
> elements, but are not meant to be protocol elements themselves.  I said I
> didn't want to get too wound up with that, though, and I don't...
> 
> ...except that it allows no room for extensibility.  And the moment you
> need another, different request, we see why this mechanism is abusive. 
> Now, you may say that you don't see any need for extensibility, but we've
> been proven wrong in those sorts of assumptions many times.
> 
> So, the discussion is about how you will deal with that.  Specifically,
> an alternative would be to have an rs-request subtype, with a
> content-type parameter such as "req=metadata" (or even use rs-metadata
> with "req=snapshot") and a rule that req= values that are not recognised
> be ignored.  If this should ever need to be extended, other "req=" values
> could be defined.  A registry could be created in future, if there turns
> out to be a need.
> 
> There are other options, as well, but the main question is why are you
> sure that no such extensibility is needed?
> 
> Also, what you're doing with content-disposition isn't in accord with
> what that field is for: it is for describing how the information in the
> message part should be presented -- not what it's meant to contain or be
> used for.  This, too, could be better handled with a content-type
> parameter.
> 
> The discussion on this point is whether thus was considered, and, if so,
> why it was rejected.
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> -- Section 7.1.1 --
> 
>   Since the SRC does not expect to receive media from the SRS, the SRC
>   typically sets each media stream of the SDP offer to only send media,
>   by qualifying them with the a=sendonly attribute
> 
> Why "typically"?  Why would it not?  Why not just remove the word? The
> same question applies to 7.2.
> 
> -- Section 8.1.4 --
> 
>   It is RECOMMENDED that an SRC or
>   Recording aware UA, when acting as a mixer, sets the CSRC list
>   accordingly, and that the SRC and SRS interpret the CSRC list
>   appropriately when received.
> 
> A few questions about this:
> "Accordingly" and "appropriately" are quite vague... any better guidance
> on what is accorded and appropriate?  For the former, I presume you're
> saying that the UA should set the CSRC list to encompass what's being
> mixed.  But I have no idea what's appropriate for the SRC and SRS to do
> when interpreting that.  Further, on "RECOMMENDED", what happens if
> someone doesn't do this as you're hoping they do?  What are the
> consequences to interop or security?
> 
> -- Section 8.1.5 --
> 
>   The ability to identify individual contributing sources is important
>   in the content of SIPREC.
> 
> I think you mean "context", yes?
> 
> -- Section 8.2.1.1 --
> 
>   UAs may receive multiple sets of RTCP Receiver Reports, one or more
>   from other UAs participating in the CS, and one from the SRS
>   participating in the RS.  A UA SHOULD process the RTCP Receiver
>   Reports from the SRS if it is recording-aware.
> 
> Is it woth mentioning what the UA is likely to do with the reports from
> other UAs (just for information, without 2119 words)?  Would the UA
> generally process them too?  Ignore them?  Doesn't matter?  Is there any
> advantage one way or another, or any advice that would be useful for
> implementors to have?
> 
>