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

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Thu, 2 Jul 2015 04:17:18 +0000

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

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Thu, 23 Jul 2015 15:27:55 +0000

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

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 23 Jul 2015 11:56:11 -0400

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

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Thu, 23 Jul 2015 17:29:58 +0000

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)

>>> request for metadata from SRS to SRC with minimal changes to the
>>>protocol
>>> ?
>>>
>>> Regards,
>>> Ram
>>>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 23 Jul 2015 17:25:29 -0400

I defer to somebody with more knowledge of xml than I have.

	Thanks,
	Paul

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Fri, 24 Jul 2015 09:51:51 +0000

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 ?

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]>,

>>>>          To: 
>>>><sip:[email-masked]>;tag=35e195d2-947d-4585-946f-098392474
>>>>>>>> The reason for asking is I still feel they have to be different
>>>>>>>>C-T
>>>>>>>> as
>>>>>>> I don't think they have to be different C-T's that surely depends
>>>>>>>on
>>>>>>> how

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 24 Jul 2015 06:46:35 -0400

> 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

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Fri, 24 Jul 2015 14:57:34 +0000

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]>,

>>>> with in <recording> with that being a top element having the name
>>>>space
>>>> as
>>>>>> We had a side discussion in the IETF and here is the proposal for
>>>>>>SRS
>>>>>> to
>>>>>>     This would take care of Barry’s concerns as we have a formal
>>>>>>syntax
>>>>>> and
>>>>>>           Via: SIP/2.0/UDP
>>>>>>srs.example.com;branch=z9hG4bKdf6b622b648d9
>>>>>>           To:
>>>>>> The type of reason XML element is tns:name. “name” is already
>>>>>>defined
>>>>>> in
>>>>>>> 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
>>>>>>>> This means that the RFC will be a dead word for most vendors on
>>>>>>>>one
>>>>>>>> hand
>>>>>>>>>> consider them as two different content-types. The C-D can be
>>>>>>>>>>same
>>>>>>>>>> as
>>>>>>>>>> both
>>>>>>>> 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