Hi, Some of the remaining issues had already been discussed, but either did not lead to text or the text was lost. Let me comment on these issues:
>> On 4. Mar 2020, at 15:38, Michael Welzl <[email protected]> wrote: > > REMAINING UNADDRESSED COMMENTS FROM KYLE ROSE: > > > 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. > > > 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. The solution for this issue was to allow implementations to change the property names in consistent ways, e.g., by replacing the dashes with underscores or removing them and use CamelCasing. The text was removed as over-specific. > * 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? The IANA registry question was explicitly postponed, be maybe we should re-iterate it now. The idea of having an „x“ namespace was rejected in fear we end up with quasi-standard properties that have an x prefix then. > > 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. We had a lengthy discussion about this and rejected it as too complex and limiting for the implementation. > > * 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. We had text saying that these should turn into Boolean when queried and should reflect whether the protocol stack chosen provides the feature. I will have to double-check whether this text is still in the description of the preference type. > MW: I agree; partially addressed: s/Required/Require wherever it's a > Preference level. > > > 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) > > > 5.2.10. Interface Instance or Type > > * These type symbols really deserve an actual registry, or at least the start > of one. Otherwise, we are likely to end up with a mess. There is already one, but that one was not useful for our matters. > > 5.2.11. Provisioning Domain Instance or Type > > * What about ordering of similar interfaces? I have a 2-SIM cellphone with > wifi. Each cellular provider will have a unique PVD. > > 5.3.2. Connection Establishment Callbacks > > * What constitutes trust verification prior to the handshake? > > 7.3.1. Sent > > * It seems like an abstract API would be helpful for the reference to the > Message to which a Sent event applies: this seems like something many, many > applications would need to do. With callbacks, the application can always > curry in a reference to the original message (that's what my event system > from ~2001 did), so maybe that should be the recommendation and the message > reference removed...? I don't have a strong feeling here other than that if > something is included then its use should be more well-defined. > > 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? > > > 7.4.7. Reliable Data Transfer (Message) > > * The default isn't "true", it's whatever the underlying connection had, > right? Ack > > > 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. > > > 8.2. Receive Events > > * "A call to Receive will be paired with a single Receive Event" or possibly > multiple ReceivedPartial Events? > > * Also, can the draft be consistent about Receive vs. Received, et al.? > > > 11. General comments > > * There's a lot of UNIXisms here that should probably be excised in favor of > a more abstract presentation. The most obvious is the use of -1 to mean > something other than the integer -1. In Python, for instance, you might want > to use None for this purpose. I would specify non-numeric values > symbolically, and maybe indicate in the appendix that a UNIX C implementation > might want to use -1 to represent such values. > > MW: agreed... TODO. > > > 11.1.10. Capacity Profile > > * Very little of this section is about capacity. Traffic Profile? > > * "High Throughput Data" might be better phrased as "Capacity-Seeking". > > _______________________________________________ > Taps mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/taps _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
