Hi Martin, On Mon, Oct 3, 2022 at 4:59 PM Martin Duke <[email protected]> wrote:
> I'm late to this discussion, but if the need is a protocol that delivers > streams without encryption, SCTP (or SCTP over UDP) is a reasonably > well-vetted choice that would appear to meet the requirements. It > certainly sounds superior to asking people to invent a new protocol. > > Exactly. The requirement to have the payload encrypted seems to be the reason why Quic was connected to HTTP over TLS. I am not sure for IoT such a requirement could be defended in every use case. (Which is not to say that the suggestions to making QUIC work in this use > case are unworkable) > > +1 Behcet > On Mon, Oct 3, 2022 at 11:38 AM Lucas Pardue <[email protected]> > wrote: > >> Hi Phillip, >> >> On Mon, 3 Oct 2022, 19:13 Phillip Hallam-Baker, <[email protected]> >> wrote: >> >>> I think we have to actually build a prototype of a transactional-first >>> transport, then build some applications over it and only then look to see >>> whether/how we might re-use QUIC. >>> >>> That is how I originally worked on HTTP, I build applications using HTTP >>> as a transport, one of which was the first Webmail service, those allowed >>> me to discover the need for content length and start working on connection >>> keepalive and framing. >>> >>> And we need to build any such system around the capabilities of modern >>> programming languages which support threads and asynchronous methods. >>> Otherwise we just end up trapped in subordination type interactions and >>> don't progress beyond RPC. >>> >>> What I am saying is, let me build something, then take a look at it and >>> tell me if/how to build it using QUIC. >>> >> >> In case I was unclear, I think building something and revisitng later >> sounds like a good approach. Look forward to seeing your progress >> >> In the meantime, and tangentially, I think its important to we provide a >> consistent reminder that QUIC is very unopinionted about the applications >> on top. This has been the case for years. I suspect many application >> protocols that already exist would straightforwardly map to QUIC. We have >> RFCs that do this, many I-Ds either individual or adopted by WGs, and I'm >> aware of many protocol mappings that are defined outside the IETF - either >> openly documented or private. >> >> Should future evolution of QUIC provide opportunity for alternative >> (re)mappings that people think would be useful, that is entirely possible >> and supported. Extension like that should probably also add a section that >> extends the applicability document to aid designers and implementers. >> >> Cheers >> Lucas >> >> >> >>> >>> On Mon, Oct 3, 2022 at 1:19 PM Lucas Pardue <[email protected]> >>> wrote: >>> >>>> Hi Behcet, >>>> >>>> >>>> On Mon, Oct 3, 2022 at 5:56 PM Behcet Sarikaya <[email protected]> >>>> wrote: >>>> >>>>> Hi Christian, >>>>> >>>>> I quickly glanced through RFC 9250 which defines DoQ and references >>>>> ALPN in RFC 7301. >>>>> Agree with Philip that DoQ does not define something that is >>>>> independent of HTTP. >>>>> >>>>> Will it come one day, we don't know? >>>>> Behcet >>>>> >>>> >>>> DoQ is an application mapping over QUIC. ALPN is an extension to TLS. >>>> DoQ might use a transactional model that maps to bidirectional streams but >>>> that is the full extent of similarities to HTTP; there is no normative >>>> dependency. >>>> >>>> RFC 9000 was written carefully to describe the interface that >>>> application-data-bearing streams can provide to applications. This is not >>>> related to HTTP, QUIC is independent of HTTP. Indeed, QUIC on its own means >>>> pretty much nothing. It needs an application mapping protocol. The >>>> recently-published applicability draft, RFC 9308 [1], is specifically >>>> written to aid designers or implementers of such mappings. Randy might find >>>> RFC 9308 informative if wishing to pursue QUIC as a transport substrate for >>>> the OT application layer traffic. >>>> >>>> Cheers >>>> Lucas >>>> >>>> [1] - https://www.rfc-editor.org/rfc/rfc9308.html >>>> >>>> >>>> >>>
