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: Tue, 4 Aug 2015 16:57:38 +0000

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

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 05 Aug 2015 12:51:08 -0400

Ram,

This looks good to me. It is what I had in mind, with all the messy
details worked out.

	Thanks,
	Paul

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Fri, 7 Aug 2015 19:23:49 +0000

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

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Sat, 8 Aug 2015 14:47:12 +0000

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

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)