Re: [MMUSIC] ICE and offer/answer terminology

On 03/05/2014 06:39 PM, Ari Keränen wrote:
> Hi all,
>
> We didn't have time for this open issue on Monday meeting so we'll take it here on the list.
>
> While ICE is no longer bound to SIP and SDP offer/answer, the document uses terms "offer" and "answer" heavily, starting in the title ("ICE: A Protocol for NAT Traversal for Offer/Answer Protocols") and abstract ("ICE can be used by any protocol utilizing the offer/answer model [...]").
>
> I think we need to update the title and abstract so that it's more clear that protocols that don't follow the o/a model are not excluded. Text suggestions are welcome. Maybe in title we call this just "ICE: A Protocol for NAT Traversal".
>
> Then, throughout the text we need to refer to the exchange of candidates somehow. Originally this was referred to as the "SDP offer" and "SDP answer". Currently we use "ICE offer" and "ICE answer". My suggestion would be to keep the "(ICE) offer/answer" terminology here but clarify in the beginning of the document that with the offer and answer we refer to the ICE candidate exchange.
>
> Opinions?

Given that we do not have any requirement that exchange of candidates
happen in a particular sequence, I suggest that we call this "exchange
of candidates", not "offer/answer".

Examples of models where offer/answer would be a misnomer:

- All participants write their candidates into a common server-side
store; participants wishing to communicate fetch the candidate sets for
the entities they wish to communicate with, as long as the candidate set
is fresh enough.

- Trickle ICE

>
>
> Cheers,
> Ari
>
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic

-- 
Surveillance is pervasive. Go Dark.