Eric pointed out that the 6125bis document should address the recent SVCB/HTTPS
RFC (in the editor’s queue, latest draft is at [1]). After talking with
Benjamin and Mike, two of the authors, this is the change we made. We don’t
think this requires another WGLC; please post if you disagree.
@@ -342,9 +345,9 @@ The following topics are out of scope for this
specification:
* Resolution of DNS domain names.
Although the process whereby a client resolves the DNS domain name of an
application service can involve several steps, for the purposes of this
- specification the only relevant consideration is that the client needs to
- verify the identity of the entity with which it will communicate once the
- resolution process is complete. Thus, the resolution process itself is
+ specification the only relevant consideration is that the client needs to
+ verify the identity of the entity with which it will communicate once the
+ resolution process is complete. Thus, the resolution process itself is
out of scope for this specification.
* User interface issues.
@@ -531,6 +534,17 @@ identify a service.
An IP address that is the result of a DNS query is not direct. Use of IP-IDs
that are not direct is out of scope for this document.
+The IETF continues to define methods for looking up information needed
+to make connections to network services. One recent example is service
+binding via the "SVCB" and "HTTPS" DNS resource record (RR) types. This
+document does not define any identity representation or verification procedures
+that are specific to SVCB-compatible records, because the use of such records
during
+connection establishment does not currently alter any of the PKIX validation
+requirements specified herein or in any other relevant specification. For
example,
+the PKIX validation rules for {{HTTP-OVER-TLS}} and {{DNS-OVER-TLS}} do not
change
+when the client uses {{SVCB-FOR-HTTPS}} or {{SVCB-FOR-DNS}}. However, it is
possible
+that future SVCB mapping documents could specify altered PKIX rules for new
use cases.
+
# Designing Application Protocols {#design}
This section defines how protocol designers should reference this document,
_______________________________________________
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta
