Re: actpass redux

On 6/9/17 3:41 PM, Roman Shpount wrote:
> 
> On Fri, Jun 9, 2017 at 3:34 PM, Paul Kyzivat <[email protected] 
> <mailto:[email protected]>> wrote:
> 
>     On 6/9/17 2:23 PM, Roman Shpount wrote:
> 
>         On Fri, Jun 9, 2017 at 2:00 PM, Paul Kyzivat
>         <[email protected] <mailto:[email protected]>
>         <mailto:[email protected]
>         <mailto:[email protected]>>> wrote:
> 
>              On 6/9/17 9:17 AM, Cullen Jennings wrote:
> 
> 
>                      On Jun 8, 2017, at 6:49 PM, Roman Shpount
>         <[email protected] <mailto:[email protected]>
>                      <mailto:[email protected]
>         <mailto:[email protected]>>> wrote:
> 
>                         Because of this, I think for the best interop,
>         offerer
>                      MUST specify actpass for both initial and
>         subsequent offers
>                      but answerer MUST be able to handle active and
>         passive setup
>                      roles as well.
> 
> 
>                  that works for me
> 
> 
>              I don't understand what this accomplishes. If you must be
>         able to
>              accept anything in a received offer, then what is gained by
>              restricting what can be used in an offer?
> 
> 
>         This is all because of legacy interop. There are legacy end
>         points that send non-actpass, so end point MUST be able to
>         accept active and passive to interop with such legacy devices.
>         There are also legacy end points that only expect actass so end
>         point MUST only send actpass to interop with such devices.
> 
> 
>     I understand that. But if you accept that legacy interop is needed,
>     then there ceases to be any reason to mandate actpass for things
>     that conform to this spec. It would be different if you were
>     proposing a path to deprecating and then dropping the legacy
>     support. If that is the intent then it is worth saying something
>     explicit about it.
> 
> 
> The situation right now is that there are implementations that send 
> offers with setup role set to active or passive.

Why is that a problem?

> So, my suggestion for 
> the language (subject to future wordsmithing) is: End points MUST set 
> setup role to actpass in all offers. End points SHOULD accept setup role 
> active or passive in an offer if interoperability with legacy end points 
> is desired.

So is it your intent to make implementation of support for responding to 
a non-actpass offer OPTIONAL? This encourages implementations to decide 
to not support legacy interop. IMO this is a bad idea because it is 
rarely possible to ensure that it won't eventually be required.

	Thanks,
	Paul