Re: [bfcpbis] Eric Rescorla's Discuss on draft-ietf-bfcpbis-rfc4583bis-26: (with DISCUSS and COMMENT)

[Christer Holmberg <[e-mail]>]

Hi,

---

>>> S 5.5.
>>>      'bfcpver' attribute in offers and answers.  The attribute value, if
>>>      present, MUST be in accordance with the definition of the Version
>>>      field in [I-D.ietf-bfcpbis-rfc4582bis].  If the attribute is not
>>>      present, endpoints MUST assume a default value in accordance with
>>>      [I-D.ietf-bfcpbis-rfc4582bis]: when used over a reliable transport
>>      the default attribute value is "1", and when used over an unreliable
>>
>> Just for clarity: UDP over TURN-TCP is an unreliable transport, right?
>
> I would assume so, but I guess that question is not BFCP specific?
>
> Sorry, what I mean is "does BFCP count it as an unreliable transport". I agree it is unreliable.

Do you think we need to add some text about it?

Related to that, if ICE is used, if both UDP and TCP candidates are offered, endpoints might not know what kind of transport will eventually be selected. Perhaps there should be a note about that?

Something like:

"Note: When ICE is used, where the candidates represent both reliable and unreliable transports, the ICE process will determine what type of transport will eventually be used."

---    
    
>>> S 10.1.
>>>   
>>>      o  MUST associate an SDP 'floorid' attribute (Section 5.4) with the
>>>         'm' line; and
>>>   
>>>      o  MUST associate an SDP 'label' attribute ([RFC4574]) with the 'm'
>>>         line of each BFCP-controlled media stream.
>>>
>>> We managed to mostly purge "associate" from BUNDLE. Can we do it here
>>> too?
>>
>> We could, but I'd prefer not to. It is not a widely used as in BUNDLE, so my suggestion is we keep it.
>
> I would prefer to lose it, but I'm not willing to go to the mat over it.

I will see what I can do.

---

    >>> S 10.2.
    >>>      o  MUST insert a corresponding 'm' line in the answer, with an
    >>>         identical 'm' line proto value [RFC3264]; and
    >>>   
    >>>      o  MUST associate a 'bfcpver' attribute with the 'm' line.  The
    >>>         answerer only indicates support of BFCP versions also supported by
    >>>         the offerer; and
    >>>
    >>> Is this an odd way of saying you must subset what the offer contained?
    >>
    >> Yes - assuming including the same set of values would still count as a subset.
    >>
    >> If so, we could say:
    >>
    >> "The versions indicated by the answer MUST be a subset of the versions indicated by the offerer in the corresponding offer."
    >
    > Yes, though perhaps the term "proper subset" is not widely known outside US technical circles, so we could say "must be the same or a subset of"

   I will modify as suggested.

Regards,

Christer