Re: actpass redux
Roman Shpount <[email protected]>
| Newsgroups | gmane.ietf.mmusic |
|---|---|
| Message-ID | <CAD5OKxttSJ+0Gr2r1=duXe2RVnMeMoTFQ9kG_qUbVUZgiiB3kA@mail.gmail.com> |
On Thu, Jun 8, 2017 at 8:12 PM, Cullen Jennings <[email protected]> wrote: > > > On Jun 5, 2017, at 6:30 AM, Eric Rescorla <[email protected]> wrote: > > > > For this reason, I am not in favor of removing the MUST for the initial > > offer. I would be fine with MUST for initial > +1 above > > > and SHOULD for subsequent. > > SHOULD seems sort of not great here in that some people will assume > everything else will do actpass because it is SHOULD and no reason not to > and other will assume that they don't have to implement actpass because is > is actually SHOULD with a hind "but we know you won't" - that combination > will not help interop > > I think I would prefer in subsequent offers to say > > MUST be actpass or the values that would not cause the roles to change. > > I think what EKR is trying to say here SHOULD be actpass and MUST be actpass or the value that would not cause the setup role change. Also note that 3pcc might cause an offer to be treated as subsequent offer by offerer and new offer by the answerer. If non-actpass setup roles are allowed in subsequent offers, they will have to be handled in initial offers as well. In that sense setup roles rules should be the same for both initial and subsequent offers. Since there are already implementations that do current role in subsequent offers, the cat is out of the bag. 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. Regards, _____________ Roman Shpount _______________________________________________ mmusic mailing list [email protected] https://www.ietf.org/mailman/listinfo/mmusic