Subject: [MMUSIC] sdpfrag

From: Flemming Andreasen <[email-masked]>
Date: Thu, 17 Dec 2015 14:46:43 -0500

Greetings

We used to have sdpfrag as a separate document (see 
https://www.ietf.org/archive/id/draft-ivov-mmusic-sdpfrag-00.txt), which 
(I believe) implied it might be applicable to other use cases than 
trickle ICE.

The sdpfrag draft has since then expired and the sdpfrag mechanism was 
instead included in the trickle-ice-sip draft (see 
https://www.ietf.org/id/draft-ietf-mmusic-trickle-ice-sip-03.txt). 
Furthermore, the content-type was changed to "trickle-ice-sdpfrag" and 
the associated description links its use to trickle ICE.

It wasn't entirely clear to the authors and chairs if the WG had agreed 
to this change or not, so we wanted to draw your attention to it. In the 
absence of comments to the contrary, we assume that people agree with 
this way forward.

Thanks

     Flemming & Bo (MMUSIC co-chairs)

---

From: Adam Roach <[email-masked]>
Date: Thu, 17 Dec 2015 14:16:47 -0600

Executive summary: I support this change.

The origin of sdpfrag as a separate document was inspired by two 
different mechanisms needing a new MIME type to serve very similar 
purposes (updating an SDP document without sending the whole state). In 
particular, we expected to make use of it in both trickle-ice, and 
pof-pan. Rather than defining the type in one and referring to it in the 
other (which created an odd dependency), we decided to pull it out on 
its own.

I think this rationale has been overtaken by events. Primarily, the 
pof-pan work has been back-burnered (or potentially abandoned) as being 
of much lower priority than the other mechanisms that RTCWEB needed. 
Secondarily, the benefits of using the same type for both mechanisms 
never really materialized. I imagined we could design them both as 
effectively "patch operations" against existing SDP states. But we 
didn't go down that path, and I suspect that there's little benefit to 
changing trickle ice to do so at this point (owing to the status of 
pof-pan).

Because the historical reason for having a separate document has fallen 
by the wayside, I see no benefit to doing so.

/a

On 12/17/15 13:46, Flemming Andreasen wrote:
> https://www.ietf.org/archive/id/draft-ivov-mmusic-sdpfrag-00.txt), 
> which (I believe) implied it might be applicable to other use cases 
> than trickle ICE.
>
> It wasn't entirely clear to the authors and chairs if the WG had 
> agreed to this change or not, so we wanted to draw your attention to 
> it. In the absence of comments to the contrary, we assume that people 
> agree with this way forward.
>
> Thanks
>
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 17 Dec 2015 15:21:52 -0500

Flemming,

I think this change was at least in part due to my comments.

There was little evidence that there would be general use for sipfrag. 
To make it work for trickle ICE it needed to have rules added about what 
subset of SDP lines was allowable. A big problem was that if you take 
valid SDP body and then strip out random lines you can entirely lose the 
meaning of the remaining lines. So I don't think a general purpose 
sipfrag makes any sense.

	Thanks,
	Paul

---

From: Thomas Stach <[email-masked]>
Date: Fri, 18 Dec 2015 00:08:33 +0100

Yes, this was the outcome of a discussion between Paul and myself.
It started here 
https://mailarchive.ietf.org/arch/msg/mmusic/0Is5ztqMIt8DT5xgjV2KnSIMNTY

We also agreed that if some other application needs an SDPfrag-ish body, 
this would need its own set of rules for the corresponding syntax and 
semantics.

I also assumed that this chage was agreed when the following request
didn't generate objections.

https://mailarchive.ietf.org/arch/msg/mmusic/BWUTsYTWwQLxHinNm__KemUPwZA

Regards
Thomas

Am 2015-12-17 um 21:21 schrieb Paul Kyzivat:
> To make it work for trickle ICE it needed to have rules added about 
> what subset of SDP lines was allowable. A big problem was that if you 
> take valid SDP body and then strip out random lines you can entirely 
> lose the meaning of the remaining lines. So I don't think a general 
> purpose sipfrag makes any sense.
>
>     Thanks,
>     Paul
>

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 18 Dec 2015 10:38:18 +0000

Hi,

When trickle ICE is used, it shall be possible to provide additional candidates.

If we want to be able to send *additional* pieces of SDP "fragmented" there would be more work to do (impacts on O/A state, and the issues mentioned by Paul, etc).

Regards,

Christer

-----Original Message-----
From: mmusic [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: 17. joulukuuta 2015 22:22
To: [email-masked]
Subject: Re: [MMUSIC] sdpfrag

Flemming,

There was little evidence that there would be general use for sipfrag. 
To make it work for trickle ICE it needed to have rules added about what subset of SDP lines was allowable. A big problem was that if you take valid SDP body and then strip out random lines you can entirely lose the meaning of the remaining lines. So I don't think a general purpose sipfrag makes any sense.

	Thanks,
	Paul