Re: [quicwg/base-drafts] Padding outside QUIC packet (#3333)

[ekr <[e-mail]>]

Well, this is lawyering, but it doesn't say "by adding", but rather
"adding...as necessary". My argument here is that it's not necessary if you
pad in the datagram.

On Fri, Jan 17, 2020 at 3:36 AM Kazuho Oku <[e-mail]> wrote:

> My point is that while I'm not against making an editorial change stating
> that a receiver should process coalesced packets of a datagram until it
> sees a broken packet, I would not prefer adding a statement that implies
> that a client might pad outside of QUIC packets, because doing so is might
> have negative effects, and trying to resolve those negative effects are
> likely to introduce complexity.
>
> To be clear, my understanding is that this issue is about a misbehaving
> client failing to talk to some servers. The specification says that an
> endpoint MUST expand the packet to 1,200 bytes by "padding to packets in
> the datagram as necessary," (section 8.1.3
> <https://quicwg.org/base-drafts/draft-ietf-quic-transport.html#section-8.1-3>)
> which explicitly means that padding should happen at the packet level, not
> at the datagram level.
>
> We might even argue that some servers not handling those broken datagram
> is a benefit, as it helps us find bugs in the client.
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <https://github.com/quicwg/base-drafts/issues/3333?email_source=notifications&email_token=AAIPLIOSM5LNHTZ4JC3RV73Q6GJ2PA5CNFSM4KFV7MQ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJHNKCA#issuecomment-575591688>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AAIPLIP42EHA6Q3RX45QSHLQ6GJ2PANCNFSM4KFV7MQQ>
> .
>


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3333#issuecomment-575748146