Re: [Wish] Use entity-tags for solving out of order PATCH requests

[Sergio Garcia Murillo <[e-mail]>]

On Thu, Mar 3, 2022 at 12:27 PM Juliusz Chroboczek <[e-mail]> wrote:

> Thanks a lot for your work, Sergio.  I think I got it now.
>
> 1. Would you consider adding guidance for server implementers about how to
> generate the ETag ?  For example, something like
>
> "The ETag could, for example, be generated by appending the ICE ufrag with
>  the ice password, or by using the timestamp of the last ICE restart."
>
> (I'm not very familiar with HTTP, but it is my understanding that a strong
> ETag must be unique over the lifetime of a resource.  I'm not quite sure
> what a resource is, and I'm not sure what data can be used to guarantee
> the properties of the ETag that are required by HTTP.  I'm sure I'm not
> the only person who would find such guidance useful.)
>

I am not sure if it is a good idea to put a guide for implementation, as
the entity-tag is an opaque value and I don't want the client side to make
any assumptions about its semantics. A simple incremental number would
work, or a uuid v4, or a timestamps with ms accuracy, or just the full ice
username.


>
> 2. Could you please spell out explicitly how the server distinguishes
> between restarts and candidates?  My understanding is that one says
> "If-Match: "*"" while the other carries a strong ETag, but I'd like to see
> it spelled out explicitly.
>

No, the differentiating between the ice restarts and tricke ice has to be
done by checking the ice username/password on the sdp fragment. Now that we
can outdated past tricke ice candidate request it should be just a matter
of checking if the username and fragment corresponds to the stored ones.


>
> 3. What should a server do if it cannot parse a candidate (say, the client
> sends an mDNS candidate, and the server doesn't implement mDNS, or the
> server is IPv6-only and the client sends an IPv4 candidate).  Should it
> return success and ignore the candidate, or should it return an error?  If
> so, which one?
>

The server should always report a 204 No content if the body has the
correct syntax and return standard 400 Bad request error codes if the body
is invalid. If the candidate is not supported (mDNS or ipv6 for
example)  the server should just silently ignore it. Do you feel that this
should go into the spec?


> 4. What should the server do if restarting ICE fails?  Should it ignore
> the restart and return the same ETag as before, should it return an error
> to the client and continue with the previous ICE generation, or should it
> return the error and close the RTP stream (with RTCP BYE)?
>

How would the ice restart fail?



>
> -- Juliusz
>