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

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Mon, 1 Jun 2015 20:46:46 +0000

I¹m hoping the authors of the metadata draft can chime in as to what they
would like to see changed here.

Cheers,
Charles

On 5/28/15, 8:52 AM, "Paul Kyzivat" <[email-masked]> wrote:

>On 5/27/15 4:10 PM, Barry Leiba wrote:
>
>> ----------------------------------------------------------------------
>> 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?
>
>I agree with Barry and Ben here: I think we should have some syntax in
>the body that indicates a request for a snapshot, and that has potential
>for future extension.
>
>> 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.
>
>I disagree with Barry here. He is an app guy, so I guess it makes sense
>that he would say this. But almost none of the Content-Dispositions used
>with SIP are actually rendered to a human. For instance "session" for SDP.
>
>I see the distinction between C-T and C-D being a distinction between
>how it is represented and how it is used. There could be two different
>C-Ts for SDP and SDPng, but they would both be C-D "session". The SIPREC
>metadata is used very differently, and C-D is the way to distinguish it
>from "session".
>
>	Thanks,
>	Paul
>
>_______________________________________________
>siprec mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/siprec

---

From: Alissa Cooper <[email-masked]>
Date: Fri, 12 Jun 2015 13:06:07 -0700

Still looking for folks to respond on this — have only seen a response from Paul.

Alissa

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Mon, 15 Jun 2015 05:19:45 +0000

Please see inline for comments

-----Original Message-----
From: Alissa Cooper <[email-masked]>
Date: Saturday, 13 June 2015 1:36 am
To: "Charles Eckel (eckelcu)" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [siprec] Barry Leiba's Discuss on
draft-ietf-siprec-protocol-16: (with DISCUSS and COMMENT)

>Still looking for folks to respond on this ― have only seen a response
>from Paul.
>
>Alissa
>

I am fine with having such a extension to use rs-metadata with req= so
that it allows for any extensions that would come in future. For the
current version of SIPREC we could use req=snapshot.
 
>>>> used for.  This, too, could be better handled with a content-type

Content-Disposition header field describes how the message body part is to
be interpreted
   by the UAC or UAS. As SIPREC metadata is used differently by recorders
than the body types like SDP the Content-Disposition “session” defined in
RFC 3261 cannot be used here.
I think its fine to have new C-D. Also I see several of other SIP RFCs
(like RFC 5621, RFC 3204) that defines new body defines its own C-D.

So we could stick with current C-D in the draft .

Regards,
Ram

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Tue, 16 Jun 2015 22:00:31 +0000

Hi Ram,

Thanks for your comments. Your suggestions align with Paul’s and mostly
address the concerns raised by Ben and Barry. They sound fine to me as
well.

I had a look at the draft and tried to determine what in the draft should
change. Either I encountered other previously undiscovered issues, or I’m
just confused regarding Content-Type and MIME types.

Section 9 reads,

  Some metadata attributes are contained in SDP, and others are
  contained in a new content type "application/rs-metadata”.

This is fine. But then the example in section 9.1 has the following:

  Accept: application/sdp, application/rs-metadata-request
  Contact: <sip:[email-masked]>;+sip.src
  Content-Type: multipart/mixed;boundary=foobar
  Content-Length: [length]

  --foobar
  Content-Type: application/sdp

  v=0
  o=SRS 2890844526 2890844526 IN IP4 198.51.100.1
  s=-
  c=IN IP4 198.51.100.1
  t=0 0
  m=audio 12240 RTP/AVP 0 4 8
  a=sendonly
  a=label:1

  --foobar
  Content-Type: application/rs-metadata
  Content-Disposition: recording-session

  [metadata content]

And Section 9.2 has the following:

  The SRS MUST NOT request a full metadata snapshot in an UPDATE
  response or in any other SIP transaction. The format of the content
  is "application/rs-metadata-request", and the body format is a simple
  text-based format. The following shows an example:

Is "application/rs-metadata-request” meant to be used for requests from
the SRS, and both application/rs-metadata and
application/rs-metadata-request need to be defined and registered in this
draft?

Cheers,
Charles

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Wed, 17 Jun 2015 09:01:59 +0000

Hi Charles,

-----Original Message-----
From: "Charles Eckel   (eckelcu)" <[email-masked]>
Date: Wednesday, 17 June 2015 3:30 am
To: Cisco Employee <[email-masked]>, Alissa Cooper <[email-masked]>,
"[email-masked]" <[email-masked]>
Subject: Re: [siprec] Barry Leiba's Discuss on
draft-ietf-siprec-protocol-16: (with DISCUSS and COMMENT)

>application/rs-metadata-request need to be defined and registered in this

I believe so. I think application/rs-metadata-request was added for SRC to
request a snapshot. For SRC whenever it indicates metadata(either in a
INVITE/UPDATE/RE-INVITE) or in a response to a request message from SRS,
it should always have content type as application/rs-metadata.

Regards,
Ram
>>>>>> message part should be presented -- not what it's meant to contain
>>>>>>or
>>>>>>be

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 17 Jun 2015 09:48:15 -0400

> it should always have content type as application/rs-metadata.

The intent was that rs-metadata be used from SRC to SRS, and
rs-metadata-request be used from SRS to SRC. The reason for different
C-Ts is that the syntax is different - one has an XML syntax, and the
other is just text with the semantics defined entirely by the C-T.

If we are going to define some fancier syntax for the latter, it might
be cleaner to simply define a new xml entity in our schema for that
purpose. Then we would only need one C-T value. There would then be a
semantic restriction about which entities are sent by SRC and SRS.

	Thanks,
	Paul

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Thu, 18 Jun 2015 09:21:25 +0000

-----Original Message-----
From: Paul Kyzivat <[email-masked]>
Date: Wednesday, 17 June 2015 7:18 pm
To: "[email-masked]" <[email-masked]>
Subject: Re: [siprec] Barry Leiba's Discuss on

>>> Is "application/rs-metadata-request² meant to be used for requests from

That¹s right. 

 "application/rs-metadata-request² from SRS to SRC and
"application/rs-metadata" whenever SRC sends metadata to SRS (either in
request messages or in response to a request from SRS)
looks good to me.

>
>If we are going to define some fancier syntax for the latter,

I don¹t see a need as the latter does not have any XML syntax as of today.
SRS is free to put in any text it likes or leave it empty as well and just
request for metadata from SRC.

Regards,
Ram

> it might

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 18 Jun 2015 13:08:35 -0400

> request for metadata from SRC.

Well, the issue was raised that we haven't provided any extensibility 
for what the SRS can say to the SRC. So we need to address that. Doing 
so probably means introducing *some* syntax into the content sent.

So, what I am suggesting is:
- make the message be XML
- use the same schema used for SRC to SRS messages
- use the same C-T and C-D for both directions
- add a new entity definition to that schema for the purpose
- specify that for SRS to SRC, only the one new entity is valid
- specify the behavior when something else is received by the SRC,
   in a way that allows for future extensibility.

	Thanks,
	Paul

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Fri, 19 Jun 2015 04:46:23 +0000

Hi Paul,

-----Original Message-----
From: Paul Kyzivat <[email-masked]>
Date: Thursday, 18 June 2015 10:38 pm
To: Cisco Employee <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [siprec] Barry Leiba's Discuss on

>>>> I believe so. I think application/rs-metadata-request was added for
>>>>SRC
>>>> to

I don’t see any issue in having a syntax (XML in which case we can re-use
the metadata XML namespace and just add one more XML element) to request
for snapshot. However don’t see it bring much value for the current
version of SIPREC protocol. In the current version, all we need is for SRS
to tell SRC that it needs a snapshot of metadata. For that, it can just
send “application/rs-metadata-request” with
content-length 0 for now and say in future have a body [ which can map to
same XML schema].

When we need to extend(say have more specific details like requesting
snapshot for a particular portion) then we would have to define a formal
XML syntax which is what is the concern form Barry here as I understand.

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.

In any case I would like to hear feedback from some more folks in WG on
this change before we go in to details of how to represent the request.

Regards,
Ram

---

From: "Hutton, Andrew" <[email-masked]>
Date: Mon, 22 Jun 2015 15:13:14 +0000

ON: 19 June 2015 00:46 Ram Mohan R Wrote:
> "application/rs-metadata-request" and "application/rs-metadata") and
> still

I don't think they have to be different C-T's that surely depends on how the XML content is defined.

Andy

---

From: "Hutton, Andrew" <[email-masked]>
Date: Mon, 22 Jun 2015 15:15:20 +0000

>    in a way that allows for future extensibility.

Although it is a fairly significant and rather late change I can see the benefit of this approach Paul's suggestion seems to make sense to me.

Andy

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Mon, 22 Jun 2015 15:42:28 +0000

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

>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