Hi all, This appears to have caused quite the controversy.
> Regarding the code point, doesn't RFC 9000 section 22.1.2 state that 4-byte or 8-byte code points should be used unless it is "especially sensitive to having a longer encoding?" Indeed it does, I somehow managed to completely miss that. I shall update to an 8-byte codepoint in this case. > Again, if the presumption here is that this is going to be deployed, then a code point would help and a provisional registration would help with collision avoidance. That is entirely the reason for my request. Given that there are plentiful codepoints I though registration prudent to remove the possibility of a clash. Thanks, Q Misell ------------------------------ Any statements contained in this email are personal to the author and are not necessarily the statements of the company unless specifically stated. AS207960 Cyfyngedig, having a registered office at 13 Pen-y-lan Terrace, Caerdydd, Cymru, CF23 9EU, trading as Glauca Digital, is a company registered in Wales under № 12417574 <https://find-and-update.company-information.service.gov.uk/company/12417574>, LEI 875500FXNCJPAPF3PD10. ICO register №: ZA782876 <https://ico.org.uk/ESDWebPages/Entry/ZA782876>. UK VAT №: GB378323867. EU VAT №: EU372013983. Turkish VAT №: 0861333524. South Korean VAT №: 522-80-03080. AS207960 Ewrop OÜ, having a registered office at Lääne-Viru maakond, Tapa vald, Porkuni küla, Lossi tn 1, 46001, trading as Glauca Digital, is a company registered in Estonia under № 16755226. Estonian VAT №: EE102625532. Glauca Digital and the Glauca logo are registered trademarks in the UK, under № UK00003718474 and № UK00003718468, respectively. On Mon, 22 Jan 2024 at 07:55, Marten Seemann <[email protected]> wrote: > I agree with Kazuho and Christian. There were doubts raised on this list > regarding the proposed protocol mechanism, and I'm surprised to see a > request for a provisional registration at this point, and for an individual > draft. This only seems justified if there's intent for internet-scale > deployment by multiple QUIC stacks. If that's the case, I'd like to learn > more about it. > > In any case, allocating a (somewhat) scarce 2-byte code point before > adoption seems premature to me, especially since this draft will likely go > through a couple of revisions (and therefore code points). Using an 8 byte > code point, as Christian and Kazuho suggested, would be the strictly better > choice. > > On Mon, 22 Jan 2024 at 14:28, Christian Huitema <[email protected]> > wrote: > >> >> >> On 1/21/2024 9:43 PM, Martin Thomson wrote: >> > On Mon, Jan 22, 2024, at 16:31, Kazuho Oku wrote: >> >> Regarding the code point, doesn't RFC 9000 section 22.1.2 state that >> >> 4-byte or 8-byte code points should be used unless it is "especially >> >> sensitive to having a longer encoding?" My feeling is that transport >> >> parameters and error codes are not sensitive, as they are used only >> >> once per the lifetime of a connection. >> > >> > That's encouragement that Q might take or not, but - as a designated >> expert - I can't really say "no" on that basis. >> > >> >> That said, I wonder if it is necessary to request a provisional >> >> registration for every individual draft. My experience has been that >> >> drafts submitted to the working group are discussed and revised. Then, >> >> as they mature, code points are fixed and registered. >> > >> > Again, if the presumption here is that this is going to be deployed, >> then a code point would help and a provisional registration would help with >> collision avoidance. This hasn't been discussed in this group, so the risk >> of collision is perhaps higher. >> > >> > I haven't asked if the intent was to deploy this tweak, but we don't >> use that as a condition of registration. >> > >> >>From my perspective, I would prefer if drafts that are seeking >> deployment choose and register provisional code points. And that drafts >> that are just ideas keep their code points set to 0xTBD. It's a tiny bit >> of clerical work to support a deployment, but it means that we don't have >> one rule for people who are discussing IETF drafts and one for everyone >> else. >> > >> >> The purpose of the BDP drafts is to manage paths with large bandwidth >> delay products, and skip the O(log2(BDP/IW10)) RTT required for ramping >> up the CWND to the desired value. There is really zero reason to >> allocate sort code points for that. >> >> -- Christian Huitema >> >>
