Hello Esko, On Sun, Jul 20, 2025 at 09:13:23PM +0200, Esko Dijk wrote: > In this case, the JP doesn't really need the anchor information. We would > preferably not send anything that's not needed. > [...] > This has somewhat higher complexity for the reader's minds [...]
yes -- the exercise of going through those is more for us to find a common mindset of what the information conveyed by pointing out a jpy URI is. The one that I think we're converging on is: > > depend on the still experimental service.arpa thing, so a simpler > > expression could be pretty much what you have (sans the coap part): > > > > <jpy://[IP_R]:p_Rj>;rt=brski.jp > > Small detail: we use brskip.rjp for advertising the JPY protocol endpoint. > Type "brski.jpy" could be an alternative name, but this might be confused > with "advertising the join proxy's service". ... whatever the precise points are (not sure if I looked it up wrong or just mistyped) -- as long as there is a distinction between "this is a CoAP resource to which BRSKI will be spoken" and "this is a point where you can forward UDP traffic to and it will eventually find a BRSKI resource" > Indeed there was a discussion some years ago, whether to use plain coap:// > instead of the "JPY message". I don't recall why but it went the direction > of the JPY message format. I figure it'll be in parts because DTLS handshakes might send multiple packets that are hard to express in a CoAP response -- anyway, I didn't mean to resume that discussion, merely to point out how thinking of the resource as a UDP forwarding point works both with a jpy:// URI and with a CoAP URI. Thanks for taking the time to do the back-and-forth, looking forward to this completing :-) c -- To use raw power is to make yourself infinitely vulnerable to greater powers. -- Bene Gesserit axiom
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list -- anima@ietf.org To unsubscribe send an email to anima-le...@ietf.org
