[core] My endpoint has two addresses

[Jim Schaad]

One of the issues that I just come up with, and might be part of an I don't
care space, is that if an endpoint has two different addresses then the
registration resource cannot have two different addresses associated with
it. You cannot have two different registration resources with the same
endpoint name. This means if I want to register both IPv6 and IPv4 (or
other address types) with the same endpoint there is a problem. I also
just realized that same issue arises with schema. These only apply if you
want to use the context parameter. If you are going to supply full URL
addresses to resources then this is doable. Given that the context
parameter is for space savings, I wonder if some method of dealing with this
should be considered. Possibly defining some type of context selector or
something?

Jim

[peter van der Stok]

Hi Jim,

Indeed this is an issue that was also brought up by Dave Thaler, where
he referred to the multiple types of coap schemes that became possible.

For the moment, we made the model such that and extension to multiple
contexts is possible, but not yet supported by the RD, given that all
these extensions are still under discussion,

Peter

Post by Jim Schaad
One of the issues that I just come up with, and might be part of an I don't
care space, is that if an endpoint has two different addresses then the
registration resource cannot have two different addresses associated with
it. You cannot have two different registration resources with the same
endpoint name. This means if I want to register both IPv6 and IPv4 (or
other address types) with the same endpoint there is a problem. I also
just realized that same issue arises with schema. These only apply if you
want to use the context parameter. If you are going to supply full URL
addresses to resources then this is doable. Given that the context
parameter is for space savings, I wonder if some method of dealing with this
should be considered. Possibly defining some type of context selector or
something?
Jim
_______________________________________________
core mailing list
https://www.ietf.org/mailman/listinfo/core

[Jim Schaad]

One way that I have thought of dealing with this is to extend the check on
endpoint uniqueness from <domain, endpoint> to <domain, endpoint, context>.
The only downside that I can see is that it makes the query on the endpoint
resource slightly more complicated.

Jim

-----Original Message-----
Sent: Friday, September 8, 2017 12:29 AM
Subject: Re: [core] My endpoint has two addresses
Hi Jim,
Indeed this is an issue that was also brought up by Dave Thaler, where he
referred to the multiple types of coap schemes that became possible.
For the moment, we made the model such that and extension to multiple
contexts is possible, but not yet supported by the RD, given that all

these

extensions are still under discussion,
Peter

Post by Jim Schaad
One of the issues that I just come up with, and might be part of an I
don't care space, is that if an endpoint has two different addresses
then the registration resource cannot have two different addresses
associated with it. You cannot have two different registration
resources with the same endpoint name. This means if I want to
register both IPv6 and IPv4 (or
other address types) with the same endpoint there is a problem. I also
just realized that same issue arises with schema. These only apply if
you want to use the context parameter. If you are going to supply
full URL addresses to resources then this is doable. Given that the
context parameter is for space savings, I wonder if some method of
dealing with this should be considered. Possibly defining some type
of context selector or something?
Jim
_______________________________________________
core mailing list
https://www.ietf.org/mailman/listinfo/core

[Christian Amsüss]

Hello Jim,
Hello Bill and Mert,

Post by peter van der Stok
For the moment, we made the model such that and extension to multiple
contexts is possible, but not yet supported by the RD, given that all these
extensions are still under discussion,

More concretely, this is where I hope that
core-coap-protocol-negotiation will take over. We're deliberately
keeping multiple-base-addresses out of resource-directory (an earlier
state already allowed more than one address) so this can be
comprehensively specified there based on model that contains only the
extension point for it.

Bill and Mert, Jim the issue Jim raised is not fully covered by the
protocol-negotiation draft or what we talked about in Prague, but
involves the choice of an Internet layer when raw addresses are used.
Will we be able to use the mechanisms introduced there in the absence of
hostnames for an IPv4 and an IPv6 addresses (or multiple IPv6
addresses)?

Best regards
Christian

[Mert Ocak]

Hi Christian,

The issue Jim raised was not covered with protocol-negotiation draft indeed in the version we discussed in Prague. That version proposed a way to expose alternative transports on a per-server basis. However, in the new version of the draft for Singapore, we are introducing a new link attribute "ol" : other locations, in which the CoAP server can expose the same resource on different locations/transports. The new attribute works as a per resource basis and can be used both on RD or on /.well-known/core. This way enables exposing resources both per-server or per-resource on the same server, something we had several discussions about in Prague. The new attribute also prevents overloading the meaning of "con", since the original idea of "con" was not intended for per-resource.

This approach can be used for exposing the same resource on different raw addresses as in the Jim's issue since we are not restricting the use of "ol" for just different transports.

Cheers,
Mert


On 21/09/2017, 15.01, "Christian Amsüss" <***@fsfe.org> wrote:

Hello Jim,
Hello Bill and Mert,

Post by peter van der Stok
For the moment, we made the model such that and extension to multiple
contexts is possible, but not yet supported by the RD, given that all these
extensions are still under discussion,

More concretely, this is where I hope that
core-coap-protocol-negotiation will take over. We're deliberately
keeping multiple-base-addresses out of resource-directory (an earlier
state already allowed more than one address) so this can be
comprehensively specified there based on model that contains only the
extension point for it.

Bill and Mert, Jim the issue Jim raised is not fully covered by the
protocol-negotiation draft or what we talked about in Prague, but
involves the choice of an Internet layer when raw addresses are used.
Will we be able to use the mechanisms introduced there in the absence of
hostnames for an IPv4 and an IPv6 addresses (or multiple IPv6
addresses)?

Best regards
Christian

--
This may seem a bit weird, but that's okay, because it is weird.
-- perldata(1) about perl variables