Hi, On Wed, 2021-01-13 at 20:06 +0100, Julian Reschke wrote: > Am 13.01.2021 um 19:55 schrieb Ted Hardie: > > ... > > While they could theoretically pre-assign it, the RFC Editor won't > > publish the document without the documents actually being available for > > retrieval. That's a big reason you get clusters. This is why we do > > downrefs to the drafts; since there is an onward pointer from the > > referenced draft to the final RFC in the tools, that's considered okay > > as anyone who seriously wants the reference can readily find it. [Note: > > my opinion on that is separate from my recitation of what I think the > > facts are.] > > ... > > Maybe we need a separate discussion about easily (or even > semi-automatically) updating published RFCs when their downrefs become RFCs.
Which isn't done at all. The main body of the RFC when published is inmutable. Thus, if you want to align any language changes or anything with the new HTTP specs when going for do a "downref" means a new RFC. That is why I didn't understand Roy's comment: > In short, there's no need to be pedantic. As soon as the QUIC RFCs > enter the RFC ed queue, we can fix their content as such including > the final protocol versions and ALPNs. If the HTTP Semantics spec > needs additional changes, we can choose those changes deliberately > without impacting any content or references within HTTP/3. We don't > xref by page number. What you can do is do a last alignment in AUTH48 with the status of HTTP semantics and cache at this point. If we want the rfc numbers of the HTTP specs, then you have to wait until they are ready and also in AUTH48. So, if the HTTP semantics and cache aren't ready when we come to AUTH48 you still have the risk of missalignment if going down the downref path. I would like to point out that just this week a PR was merged to the HTTP/3 spec to align with the latest changes done in the HTTP semantics. So the risk for missalignment is not zero here. Sure the HTTP specs are mature, but you can still end up in a situation where it becomes hard to interpret HTTP/3 correctly when section numbering and terms don't align. This might be primarily directed to Ted. However, I don't understand how we could do a downref in this case when we have a normative reference to a IETF draft. This case is not the type of downref that RFC 3967 discusses, where the normatively referenced document is an lower maturity (Informational or Experimental) RFC or an external document. So I want to understand what process diviation Ted really had in mind when he suggested this? Sorry to be a damper, but I don't see we can do Option 3) within our process without violating our process. Cheers Magnus Westerlund Responsible AD
smime.p7s
Description: S/MIME cryptographic signature
