P.S. to that, following an off-list comment:

By "URI resource name", do you mean "URI path component"? "Path" seems to be 
the official name for what follows the host in a URI, according to RFC3986.

"Resource name" is confusing because a URN is different: RFC8141.

Regards
   Brian Carpenter

On 02-Nov-22 08:58, Brian E Carpenter wrote:
On 31-Oct-22 22:24, Esko Dijk wrote:
cases where the Registrar would configure another resource (e.g. /j or
    > /join or whatever) and in such case a Uri-Path option would be needed.

Okay, but I'd like to not do that :-)

Okay, I see your point - let's go for the '/' resource option and see if reviewers 
further down the line are okay with that. I just noticed that when GRASP discovery is 
used (service "BRSKI_RJP") the Join Proxy only discovers IP address and port so 
has to make an assumption on the URI resource name being '/'.

Two comments there:

1) It would be trivial to extend the definition of the BRSKI_RJP objective by 
giving
it a meaningful value field, such as a string defining the URI resource name. 
Like:

     objective-value   =  text      ; URI resource name

2) At the moment draft-ietf-anima-constrained-join-proxy cuts a corner in its 
definition of BRSKI_JP. Even if you want to save typing by citing Fig. 10 of 
RFC8995, you need to
add an IANA Consideration formally registering the objective (like section 8.7 
of
RFC8995).

Regards
      Brian


If any other CoAP resource would be possible as well, then that resource name would have 
to be advertised in GRASP too. We could say that because our service is being discovered 
on a particular port (typically differing from the default CoAP port as shown in Section 
5.1.1 example) we don't have the issue that we would interfere with other resources using 
name "/".

So, no Uri-Path option is equivalent to /?
Yes! It's also equivalent to the same URI without the trailing slash, which is 
the format we show in Section 5.1.1.

Regards
Esko


-----Original Message-----
From: Michael Richardson <mcr+i...@sandelman.ca>
Sent: Wednesday, October 26, 2022 19:39
To: Carsten Bormann <c...@tzi.org>
Cc: Esko Dijk <esko.d...@iotconsultancy.nl>; anima@ietf.org; c...@ietf.org
Subject: Re: [Anima] [core] ANIMA constrained-join proxy revision to use CoAP


Carsten Bormann <c...@tzi.org> wrote:
      >> I'm not 100% sure if for a resource at the root (/), one Uri-Path
      >> Option with 0 length is needed or if 0 Uri-Path Options can be used.
      >> Or if both methods would be valid.

      > That is a well-known idiosyncracy in the URI format.

      > Have a look at: https://www.rfc-editor.org/rfc/rfc7252#section-6.4

      > Step 8 treats coap://foo and coap://foo/ in the same way:

      >        If the value of the <path> component of |url| is empty or
      > consists of a single slash character (U+002F SOLIDUS "/"), then move to
      > the next step.

So, no Uri-Path option is equivalent to /?


--
Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works
   -= IPv6 IoT consulting =-



_______________________________________________
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

_______________________________________________
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Reply via email to