Re: [MMUSIC] Partial Offer/Partial Answer draft - MIME type value

[Christer Holmberg <[e-mail]>]

Hi,

I think everyone agrees that in order to make POF/PAN work, certain intermediaries must support the mechanism. I didn't suggest that using app/sdp would make POF/PAN work with non-supporting intermediaries. I only said that it would be easier to identify such non-supporting intermediaries, as they would reject the POF.

But, if we don't even agree that non-supporting intermediaries would reject a POF, but rather think that media e.g. has been disabled, that advantage goes away.

Part of innovation is to discuss/explore different ideas - even the SBC-friendly ones :)

Regards,

Christer

Sent from my Sony Ericsson Xperia arc S

Paul Kyzivat <[e-mail]> wrote:


Adam,

I'm pretty sure that Hadriel will speak up in a minute and say that the
SBCs only do what they do because that is what administrators want them
to do.

So on one hand it is the administrators that we should curse, not the
vendors of middleboxes.

OTOH, ISTM that the administrators and middlebox vendors are
codependent. Administrators do stuff because they can, even if it is a
bad idea.

I guess ultimately it is a competition. Admins want to forbid anything
they don't fully understand. But that prevents introduction of new stuff.

So ultimately I think we just have to define the new stuff, even if the
middleboxes will often break it. And then let demand push the admins and
middlebox vendors to allow it.

        Thanks,
        Paul

On 10/18/13 6:39 PM, Adam Roach wrote:
> On 10/18/13 16:16, Christer Holmberg wrote:
>> That's why Hadriel should write all our RFCs
>
> You know, there was a point in time at which I would have suspected that
> would work. I would have believed that it would have produced specs that
> would, at the very least, play nicely with middleboxes. And vice-versa.
> Because if there's one person playing in this space who understands
> middleboxes, I would think Hadriel is that person.
>
> But consider the INSIPID effort, which Hadriel did, in fact, author.
>
> At the end of a year and a half of hashing out details, Hadriel
> explained (in a personal, not corporate capacity) that the resulting
> identifier is *unlikely* to make it through middleboxes. Keep in mind
> that the only reason for this work to have occurred is to create an
> identifier that makes it through middleboxes.
>
> Um. What?
>
>  From that, I think the lesson to take away is that middleboxes are
> going to do what middleboxes do, and that we are utter fools for trying
> to appease them. I think it also demonstrates that the Faustian deals we
> cut every time we concede defeat to middlebox behavior are even more ill
> conceived than we first imagined: at least Mephistopheles honored his
> end of the deal.
>
> I think this also tells us that no one can act as an emissary for
> middleboxes, even someone as experienced as Hadriel. Claims about what
> middleboxes do, don't do, can do, or won't do should be viewed with
> extreme skepticism. Any such statements are so heavily caveated as to be
> devoid of meaning.
>
> To be clear, this isn't intended as a smear against Hadriel. When he
> delivered the message that INSIPID was pretty well worthless, he did so
> exactly as a messenger and not as a perpetrator. The failure of
> middleboxes to use this mechanism we designed exclusively for them is
> not his fault. No, this is a criticism leveled at middlebox vendors in
> general. Even where the IETF makes concessions to middleboxes, the
> middleboxes don't play nicely with those concessions. Nothing could have
> been a more direct pander to middleboxes than INSIPID, and its failure
> at their hands is apparently complete and without mitigation.
>
> The writing on the wall is clear. This kowtowing to unknowable and
> infinitely mutable middlebox requirements is both unproductive and
> harmful to innovation. It needs to stop. And it needs to stop now. It's
> done untold damage to SIP's ability to innovate. I have no interest in
> inviting the rampaging bull that gored SIP into WebRTC's home. I'm done
> entertaining arguments that we need to fetter innovation in order to
> accommodate implementations that have no interest in what the IETF has
> to say.
>
> /a
>
> P.S. Yes, I know your comment was meant to be tongue-in-cheek, but it
> threw into vivid relief the reality that the IETF's attempts to play
> nice with middleboxes have been utterly unrequited.
>