________________________________ From: Lachlan Keller <notificati...@github.com> Sent: Sunday, April 23, 2023 23:38 To: ietf-wg-alto/draft-ietf-alto-new-transport <draft-ietf-alto-new-transp...@noreply.github.com> Cc: Subscribed <subscri...@noreply.github.com> Subject: Re: [ietf-wg-alto/draft-ietf-alto-new-transport] To what extent this work adheres to "Building Protocols with HTTP" BCP (Issue #4)
WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros. This work adheres fully to RFC 9205 for the following reasons (all citations refer to RFC 9205): * TIPS does not “ redefine, refine, or overlay the semantics of generic protocol elements such as methods, status codes, or existing header fields” and instead focuses “protocol elements that are specific to [the TIPS] application -- namely, [its] HTTP resources” (Section 3.1). * There are no statically defined URI components (Section 3.2). * No minimum version of HTTP is specified by TIPS which is recommended (Section 4.1) * This work follows the advice that “When specifying examples of protocol interactions, applications should document both the request and response messages with complete header sections, preferably in HTTP/1.1 format [HTTP/1.1].” (Section 4.1 * The draft does use URI templates which is recommended (Section 4.2) * TIPS follows the pattern that “a client will begin interacting with a given application server by requesting an initial document that contains information about that particular deployment, potentially including links to other relevant resources. Doing so ensures that the deployment is as flexible as possible (potentially spanning multiple servers), allows evolution, and also gives the application the opportunity to tailor the "discovery document" to the client.” (Section 4.4.1) * TIPS uses existing HTTP schemes (Section 4.4.2) * TIPS defines its errors “to use the most applicable status code” (Section 4.6) * TIPS does not “make assumptions about the relationship between separate requests on a single transport connection; doing so breaks many of the assumptions of HTTP as a stateless protocol and will cause problems in interoperability, security, operability, and evolution.” (Section 4.11) The only relationship between requests is that a client must make a request to first discover where a TIPS view of resource will be served, which is consistent with URI discovery in Section 4.4.1. * Section 4.14 of RFC 9205 notes that there are quite a few caveats with using server push, mostly because of lack of widespread support. We, the authors, have considered these factors and have still decided server push can be valuable in the TIPS use case. — Reply to this email directly, view it on GitHub<https://github.com/ietf-wg-alto/draft-ietf-alto-new-transport/issues/4#issuecomment-1519174657>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AA6RQJLKPA4K3GT2FLFB7O3XCWOODANCNFSM6AAAAAAV2AXZWI>. You are receiving this because you are subscribed to this thread.Message ID: <ietf-wg-alto/draft-ietf-alto-new-transport/issues/4/1519174...@github.com>
_______________________________________________ alto mailing list alto@ietf.org https://www.ietf.org/mailman/listinfo/alto
