We seem to need to decide what "Reliable Data Transfer" means to an Application.

My point. expanding here a little, is:

TAPS has to by default do something if the app doesn't say what it wants. So this is really about the default service chosen by TAPS.  A safe assumption is that an app not designed for reordering, loss, duplication etc  will receive the default service, that's why I think this should be "Reliable Data Transfer".

Apps that CAN handle all of these need to tell the TAPS Interface that they do not need a "Reliable Data Transfer". If the app does not do this, and happens to exist on a stack that only supports datagrams, then it would not be able to connect.

Gorry

On 02/04/2020 13:32, mwelzl wrote:

List discussion:

*Kyle:*

    7.4.7. Reliable Data Transfer (Message)

      * The default isn't "true", it's whatever the underlying
        connection had, right?

*@philsbln <https://github.com/philsbln>*:

    Ack

*@mwelzl <https://github.com/mwelzl>*:

    I agree too, but doesn’t this warrant some more discussion?
    I think our defaults all translate into things that can work in
    some way when TCP is used - with “Reliable Data Transfer” being an
    exception, as it just can’t work in a UDP-only system. Are there
    others? I think I’ll open an issue for this one.

*@gorryfair <https://github.com/gorryfair>*:

    I don't agree at all - To me this was just the default behaviour
    of the API.

    I think the default needs to be "reliable" and an app will have to
    over-ride that to get datagram/unreliable operation. That doesn't
    mean if you have only UDP (for instance) that you can't offer
    TAPS, to me it simply means you always need to say that the app
    wants this service.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <https://github.com/ietf-tapswg/api-drafts/issues/520>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABYLLEX6WIN7O2AJT7BBDC3RKSAWLANCNFSM4L2L2TNQ>.

_______________________________________________
Taps mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/taps

Reply via email to