Adam Roach <[email protected]> wrote: > It's worth noting that, with relatively rare exception, > application-layer protocols aren't really going to have a compelling > reason to use numeric representation for transports. See, for example, > <https://www.iana.org/assignments/sip-parameters/sip-parameters.xhtml#sip-transport> > and > <https://www.iana.org/assignments/sdp-parameters/sdp-parameters.xhtml#sdp-parameters-2>.
> At best, even if you limit this to protocols that use numbers to
> represent transports [1] , you might end up with some kind of unified
> registry, similar to what we did with
> <https://www.iana.org/assignments/message-headers/message-headers.xhtml>,
> although I've never been able to ascertain the value of that approach
> over having four different tables.
Noting that we can in fact, omit the IANA indirection, and put something like
'rfc9123' in as the actual value. I'm not sure that is a good idea for a
a number of real reasons. At this point, we need to indicate *UDP*, or *TCP*
with flexibility to specify SCTP in the future.
There was a further locator that I tried to create, see:
https://tools.ietf.org/html/draft-ietf-anima-bootstrapping-keyinfra-06#section-3.1.2
which was to use an IPIP tunnel. The use of '41' was disputed, and maybe
this is a case where it should have been a literal 'ipip' or some such.
--
Michael Richardson <[email protected]>, Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
