Add one more pointer to Framers #442
Conversation
draft-ietf-taps-interface.md
Outdated
| @@ -1378,6 +1378,10 @@ It can be used to identify send events (see {{send-events}}) related to a specif | |||
| The optional endOfMessage parameter supports partial sending and is described in | |||
| {{send-partial}}. | |||
|
|
|||
| Framers can be used to instruct the transport service to pre- or suspend the message data with | |||
| additional information that can be used at the reeceiver to detect messages bourndaries. This | |||
| is further decribed in {{framing}}. | |||
There was a problem hiding this comment.
"pre- or suspend" doesn't seem right. I think you mean to say "pre- or append" - and then it would have to be "pre- or append additional information to the message data" rather than "message data with...". Also, I'm not sure it's correct to say that a "transport service" is instructed to do something? Finally, there are typos ("reeceiver" and "bourndaries").
I suggest to replace the first sentence with:
"Framers can be used to instruct the transport system to extend the message data with additional information that can be used at the receiver to detect message boundaries.".
There was a problem hiding this comment.
Actually "instruct" is probably really not the right term here..
There was a problem hiding this comment.
Thanks. And I think "instruct" is ok (I don't have a better idea)
|
Done |
| @@ -1378,6 +1378,10 @@ It can be used to identify send events (see {{send-events}}) related to a specif | |||
| The optional endOfMessage parameter supports partial sending and is described in | |||
| {{send-partial}}. | |||
|
|
|||
| Framers can be used to extend or modify the message data | |||
| with additional information that can be processed at the receiver to detect message | |||
There was a problem hiding this comment.
| with additional information that can be processed at the receiver to detect message | |
| with additional information that can be processed at the receiver and to determine message |
There was a problem hiding this comment.
Now this reads strangely - as if processing at the receiver is one thing, and determining message boundaries is another. First, what's your motivation to change it - what else would you want to do with framers at the receiver? This text could be changed to say ", e.g., to determine message boundaries at the receiver" - which would read better, but immediately raise the question: "what else?". So we'd need another example.
There was a problem hiding this comment.
I agree with Michael that the proposed changed reads a bit awkward. I'd prefer to just not change it
There was a problem hiding this comment.
The motivation was to clarify that framers can be used for other things than "just" determining message boundaries, e.g., extracting information and making them available through the message context. – it is a nit here anyway
There was a problem hiding this comment.
Then I suggest to keep the old text. We elaborate on what framers can do in the {{framing}} section that this points too anyway.
| @@ -1378,6 +1378,10 @@ It can be used to identify send events (see {{send-events}}) related to a specif | |||
| The optional endOfMessage parameter supports partial sending and is described in | |||
| {{send-partial}}. | |||
|
|
|||
| Framers can be used to extend or modify the message data | |||
| with additional information that can be processed at the receiver to detect message | |||
There was a problem hiding this comment.
Now this reads strangely - as if processing at the receiver is one thing, and determining message boundaries is another. First, what's your motivation to change it - what else would you want to do with framers at the receiver? This text could be changed to say ", e.g., to determine message boundaries at the receiver" - which would read better, but immediately raise the question: "what else?". So we'd need another example.
No description provided.