Subject: [MMUSIC] Fwd: Re: Some issues with draft-ietf-mmusic-trickle-ice-sip-02

From: Thomas Stach <[email-masked]>
Date: Fri, 11 Sep 2015 09:02:53 +0200

All,
when responding to Simon's review of draft-mmuisc-trickle-ice-sip I 
recognized that this never made its way to the MMUSIC list.
Sorry for that.
So, if nobody objects by end of next week we will change the 
content-type ot the INFOs to application/trickle-ice-sdpfrag.

Regards
Thomas

-------- Weitergeleitete Nachricht --------
Betreff: 	Re: [MMUSIC] Some issues with 
draft-ietf-mmusic-trickle-ice-sip-02
Datum: 	Wed, 29 Jul 2015 18:12:22 +0200
Von: 	Thomas Stach <[email-masked]>
An: 	Paul Kyzivat <[email-masked]>, Emil Ivov <[email-masked]>

Paul,

on your last point see below.

<snip/>
>
> And that constraint would be *enhanced* if the content-type were
> application/trickle-ice-sdpfrag, rather than just application/sdpfrag.
>
>>> ISTM that having a content-type that is specific to the allowed
>>> content would be preferable. If that is done, then there ceases to be
>>> any real need for sdpfrag.
>>>
>>>>> It does turn out that the definition of trickle-ice-sdpfrag is
>>>>> consistent with the syntax of sdp-frag. So there isn't a big problem.
>>>>> If you remove/replace the textual definition of sipfrag in 8.1 then
>>>>> things are consistent and make sense.
>>>>>
>>>>> But is there any need for application/sdpfrag? Wouldn't it be more
>>>>> straightforward to define application/trickle-ice-sdpfrag?
>>>> My understanding from IETF90 was that there was consensus that the
>>>> principle of taking vaild SDP and remove arbitrary lines should be
>>>> kept,
>>>> but there need to be application-specific contraints that define the
>>>> semantics of a specific sdpfrag body.
>>>> Since your issues can be fixed quite easily there isn't need to
>>>> deviate
>>>> from that concept.
>>>
>>> I agree that it *can* be fixed as you say. The question is whether
>>> that is the best way forward.
>> Maybe not the best way, but certainly a pragmatic way. Engineers often
>> don't need it perfect, it's ok if it works just good enough.
>> As next step I propose to correct the ABNF based on what we have now and
>> continue from there.
>
> Certainly it will work if the syntax for sdpfrag is "fixed".
>
> An alternative is:
>
> - drop all mention of application/sdpfrag
>
> - instead, define content-type application/trickle-ice-sdpfrag, using
>   the syntax in section 9.6.
I had a chat with Emil yesterday.
He also expressed the opinion that a generic application/sdpfrag MIME
type is no longer necessary.
So, if nobody else objects by Friday, say, I'd modify the next version
based on your proposal.

Regards
Thomas

>     Thanks,
>     Paul