On Wed, Mar 4, 2020 at 9:41 AM Michael Welzl <[email protected]> wrote:
> 2. Terminology and Notation > > * The notation "Sender -> Event" says nothing about who receives the > event. Is it just assumed to be the application in the context of the > particular event (e.g., a thread processing a particular connection)? > > MW: We have the following statement in this section: "Events could be > implemented via event queues, handler functions or classes, communicating > sequential processes, or other asynchronous calling conventions." > I wonder why this isn't enough information? E.g., if handlers are used, > then the recipient of the event is a pre-registered handler - and handlers > must therefore be registered before events can occur; this function isn't > visible in the API because this is platform- and language-specific. > After some thought, I think I'm okay with this now. It feels like one of those things that would make perfect sense if I were actually implementing a TAPS interface. > 4.2.1. Transport Property Names > > * The use of dashes in property names means they will necessarily look > different in almost every widely-used language, in which dash is an > operator. > Following on to the discussion later in the thread, CamelCase would probably be an improvement from this perspective. Underscores would also be fine. > * If we're not currently asking IANA to create a registry of property > names or namespaces, should we provide a recommendation that such symbols > not listed explcitly in this document be prefixed with some experimental > identifier? > Can't remember where I saw objection that this creates the possibility of a bunch of long-lived X-* properties. To that I respond: which is worse? A complete free-for-all, or a recommendation to have the free-for-all confined to an X- namespace? Do properties starting with X- just offend engineering sensibilities? One "right" alternative is a documentation-required registry, but does that raise the bar too high? How about a TAPS wiki as a compromise? The important outcome is that properties be well-defined and not conflict with each other. Since these properties have entirely local effects (e.g., they don't get encoded as options and transmitted to the peer), we probably don't need the level of precision motivating option registries, for instance. Is there precedent at the IETF for a registry mechanism less formal that what IANA provides? 5.2. Specifying Transport Properties > > * There are a lot of choices being made about how users will want to > prioritize transport protocol selection. How confident are we that, for > instance, path selection should take priority over protocol selection? I > think that's right, but I wonder if it might not make more sense to have > two interfaces: one that provides a purely numeric priority ordering of > preferences, and one (based on the existing 5-level preferences) that maps > into it. > I'm okay with whoever said that this is unworkable. I'm sure I missed the original discussion. > * Using the same enum (Require(d[sic])/Avoid/Ignore) for the queried > output of selected properties seems like a shortcut that will lead to some > confusion. > > MW: I agree; partially addressed: s/Required/Require wherever it's a > Preference level. > FWIW, my objection to the other issue (using a normative term as an indication of what was chosen) isn't that it's underspecified, only that it's confusing. I put it roughly in the same category as specifying -1 as an error indicator in an abstract API. Is the idea that the output parameters could be fed into the protocol selection logic for a subsequent connection to select the same protocol? Is that useful? > 5.2.5. Use 0-RTT Session Establishment with an Idempotent Message > > * I'll repeat the same statement I made at the mic a few years ago: > idempotency != replay-safe. DELETE is idempotent, but not safe for replay > because someone might have done a PUT or POST in the meantime. > > MW: I remember you saying this, sorry that we haven't addressed it yet! I > didn't understand - is your concern about replaying that a Message may > arrive later, i.e. as Message X, Messages Y and Z in between, then Message > X again? => if so, are you saying that this could happen with TFO or > QUIC? (I didn't think so) > What I mean is maybe best illustrated by 0RTT in TLS or QUIC. If a user sends a 0RTT DELETE /object, followed by a PUT /object, then within the replay window and without any replay prevention at the application layer, an attacker could replay the 0RTT DELETE /object and cause the object to be deleted again. DELETE is idempotent but it's not safe to replay. 7.3.3. SendError > > * Is there a reason why a single messageContext object is used for both > sends and receives? I probably missed the original discussion about this, > but I'd like to understand the reasoning. > > MW: I don't get this, where does it say that it's only a single object? Or > do you mean that it's the same type? Why is that problematic? > Same type. (Maybe I should have said "class" instead of "object".) For example, the "lifetime" property makes sense as metadata for sends, but is completely irrelevant to the receiver. The same is true of several other message properties. It might make sense for an implementation to use a single type to represent metadata both for sends and receives, but is that also true for an abstract API? > 8. Receiving Data > > * A connection can be used to receive data if it is not configured as > unidirectional transmit. > > MW: that's obviously correct - but I can't find a statement that would > contradict what you say here. > "Once a Connection is established, it can be used for receiving data." Not true if it's a unidirectional connection. I'll take a look at the subsequent replies and respond at the end of the thread to anything that I didn't cover here.
_______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
