Subject: [core] draft-ietf-core-resource-directory

From: "Kovatsch Matthias" <[email-masked]>
Date: Thu, 19 May 2016 11:03:16 +0000

Hi Michael

I got a question whether it is possible to register multiple endpoints (ep) from the same (socket) address. The use case is a device/service with multiple virtual endpoints or a gateway that provides multiple logical endpoints.

I did not have the time to test this in my implementation, but this should be possible out of the box: The same socket address registers each virtual/logical endpoint with different endpoint names and receives different handles (Location-Paths) from the RD.

I propose to include an example in the document.

Best regards
Matthias

---

From: Michael Koster <[email-masked]>
Date: Thu, 19 May 2016 06:00:46 -0700

Hi Matthias

Yes, I believe this should be expected to work, though I have not tested it with any implementation.

The RD should maintain a database by unique endpoint ID with associated scheme/host/port addressing information that it determines from the request, or has been set explicitly with con= on registration.

Of course, if the device registers the same resource in both registrations, RD would return the same link value.

I will make a note to state this explicitly in the RD draft and provide an example.

Best regards,

Michael

> On May 19, 2016, at 4:03 AM, Kovatsch Matthias <[email-masked]> wrote:
> 
> Hi Michael
>

---

From: "Subramaniam, Ravi" <[email-masked]>
Date: Thu, 19 May 2016 15:05:04 +0000

Hi Michael/Matthias,

Apologies if I am missing the point...

There are a couple of ways to interpret the use case that Matthias indicates " The use case is a device/service with multiple virtual endpoints or a gateway that provides multiple logical endpoints."

1. One is using the "authority" - in which case different "authorities" map to the same endpoint - using multiple unique endpoint ID (as authority) that maps to the same (socket) address. In this case the device/server would need to register the Resource URIs and then endpoint information for each unique endpoint ID. 
2. The other is to use the "path" - in this case only one endpoint needs to be registered with RD. The server demuxes on info that the server has embedded into the path.

Both these should be possible, right?

Ravi 

-----Original Message-----
From: core [mailto:[email-masked]] On Behalf Of Michael Koster
Sent: Thursday, May 19, 2016 6:01 AM
To: Kovatsch Matthias <[email-masked]>
Cc: [email-masked] WG <[email-masked]>
Subject: Re: [core] draft-ietf-core-resource-directory

Hi Matthias

Best regards,

Michael

> I propose to include an example in the document.

_______________________________________________
core mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/core

---

From: "Kovatsch Matthias" <[email-masked]>
Date: Thu, 19 May 2016 17:21:35 +0000

Yes, these are exactly the two cases to which I was referring:

virtual endpoints: The server on a single socket address uses the Uri-Host to multiplex incoming requests (similar to Apache vhosts)
logical endpoints: The server uses the Uri-Path prefixes to multiplex, like a gateway that translates to another technology and maps different devices into its resource structure.

As Michael said, the RD will manage each list of links under a different "endpoint name", but from the outside (on the lookup interface) one will see just links that all point to the same socket address. Using the "context", a server with virtual endpoints could provide different authorities/Uri-Host names ("sub-domains") that would also be visible in the list of links from the lookup interface.

Best regards
Matthias

> From: Subramaniam, Ravi [mailto:[email-masked]]
> Sent: Donnerstag, 19. Mai 2016 17:05
> To: Michael Koster <[email-masked]>; Kovatsch Matthias
> <[email-masked]>
> Subject: RE: [core] draft-ietf-core-resource-directory
> 
> Hi Michael/Matthias,
> 
> There are a couple of ways to interpret the use case that Matthias indicates "
> The use case is a device/service with multiple virtual endpoints or a gateway
> that provides multiple logical endpoints."
> 
> 1. One is using the "authority" - in which case different "authorities" map to the
> same endpoint - using multiple unique endpoint ID (as authority) that maps to
> the same (socket) address. In this case the device/server would need to register
> the Resource URIs and then endpoint information for each unique endpoint ID.
> 2. The other is to use the "path" - in this case only one endpoint needs to be
> registered with RD. The server demuxes on info that the server has embedded
> into the path.
> 
> The RD should maintain a database by unique endpoint ID with associated
> scheme/host/port addressing information that it determines from the request,
> or has been set explicitly with con= on registration.
> 
> > I got a question whether it is possible to register multiple endpoints (ep) from
> the same (socket) address. The use case is a device/service with multiple
> virtual endpoints or a gateway that provides multiple logical endpoints.
> >
> > I did not have the time to test this in my implementation, but this should be
> possible out of the box: The same socket address registers each virtual/logical
> endpoint with different endpoint names and receives different handles
> (Location-Paths) from the RD.
> >

---

From: "Subramaniam, Ravi" <[email-masked]>
Date: Thu, 19 May 2016 17:34:41 +0000

Hi Matthias,

Please see inline ...

Ravi

-----Original Message-----
From: Kovatsch Matthias [mailto:[email-masked]] 
Sent: Thursday, May 19, 2016 10:22 AM
To: Subramaniam, Ravi <[email-masked]>; Michael Koster <[email-masked]>
Cc: [email-masked] WG <[email-masked]>
Subject: RE: [core] draft-ietf-core-resource-directory

virtual endpoints: The server on a single socket address uses the Uri-Host to multiplex incoming requests (similar to Apache vhosts) logical endpoints: The server uses the Uri-Path prefixes to multiplex, like a gateway that translates to another technology and maps different devices into its resource structure.

As Michael said, the RD will manage each list of links under a different "endpoint name", but from the outside (on the lookup interface) one will see just links that all point to the same socket address. Using the "context", a server with virtual endpoints could provide different authorities/Uri-Host names ("sub-domains") that would also be visible in the list of links from the lookup interface.
[Ravi : ] One option is as you mention - where the RD does the "resolution" and serves up resolved URIs (i.e. "resolved" URI-Hosts). Another options is to have more stable URIs - i.e. URI-Host is something like a UUID (that is context independent) or a hostname (that is unique in context/domain) and then the Client retrieve the end point mappings (either separately or together on the look up Resource) and then uses that information to "resolve" the URIs on the Client. I am discussing both approaches in OCF, since the latter will allow client to choose a different comms technology if required while the former is useful for homogeneous comms. Also the latter allows for separate resolution schemes.

Best regards
Matthias

> The use case is a device/service with multiple virtual endpoints or a 
> gateway that provides multiple logical endpoints."
> 
> 1. One is using the "authority" - in which case different 
> "authorities" map to the same endpoint - using multiple unique 
> endpoint ID (as authority) that maps to the same (socket) address. In 
> this case the device/server would need to register the Resource URIs and then endpoint information for each unique endpoint ID.
> 2. The other is to use the "path" - in this case only one endpoint 
> needs to be registered with RD. The server demuxes on info that the 
> server has embedded into the path.
> 
> The RD should maintain a database by unique endpoint ID with 
> associated scheme/host/port addressing information that it determines 
> from the request, or has been set explicitly with con= on registration.
> 
> Of course, if the device registers the same resource in both 
> registrations, RD would return the same link value.
> 
> > On May 19, 2016, at 4:03 AM, Kovatsch Matthias 
> > <[email-masked]>
> wrote:
> >
> > Hi Michael
> >
> the same (socket) address. The use case is a device/service with 
> multiple virtual endpoints or a gateway that provides multiple logical endpoints.
> >
> possible out of the box: The same socket address registers each 
> virtual/logical endpoint with different endpoint names and receives 
> different handles

---

From: "Kovatsch Matthias" <[email-masked]>
Date: Fri, 20 May 2016 07:41:02 +0000

There shouldn't be any implication for RD in this. The registering entity simply needs to provide this UUID as context and the RD serves that in its lookup results. The virtual and logical cases here should also work.

You then need a DNS-like service to resolve the UUIDs / OCF URIs to the preferred "socket address" (which depends on the communications).

Do I read you correctly that you want to ensure that the RD draft reflects this explicitly? :)

Ciao
Matthias

-------- Original message --------
From: "Subramaniam, Ravi" <[email-masked]>
Date: 5/19/16 19:34 (GMT+01:00)
To: Kovatsch Matthias <[email-masked]>, Michael Koster <[email-masked]>
Cc: "[email-masked] WG" <[email-masked]>
Subject: RE: [core] draft-ietf-core-resource-directory

Hi Matthias,

Please see inline ...

Ravi

-----Original Message-----
From: Kovatsch Matthias [mailto:[email-masked]]
Sent: Thursday, May 19, 2016 10:22 AM
To: Subramaniam, Ravi <[email-masked]>; Michael Koster <[email-masked]>
Cc: [email-masked] WG <[email-masked]>
Subject: RE: [core] draft-ietf-core-resource-directory

Best regards
Matthias

---

From: "Subramaniam, Ravi" <[email-masked]>
Date: Fri, 20 May 2016 16:17:25 +0000

Hi Matthias,

Thanks yes, that would be great. (Actually the "DNS-like" service can be similar to Resource discovery and so a separate service is not necessary).

BTW: end point information can also be returned as part of Resource retrieval - so the resolution can be "piggybacked" even though endpoint information is distinct. This depends on how the endpoint information is represented. Need to read the draft to make sure that this method is also possible.

Ravi

Sent: Friday, May 20, 2016 12:41 AM

Ciao
Matthias

-------- Original message --------
From: "Subramaniam, Ravi" <[email-masked]<mailto:[email-masked]>>
Date: 5/19/16 19:34 (GMT+01:00)
To: Kovatsch Matthias <[email-masked]<mailto:[email-masked]>>, Michael Koster <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked] WG<mailto:[email-masked]%20WG>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [core] draft-ietf-core-resource-directory

Hi Matthias,

Please see inline ...

Ravi

-----Original Message-----
From: Kovatsch Matthias [mailto:[email-masked]]
Sent: Thursday, May 19, 2016 10:22 AM
To: Subramaniam, Ravi <[email-masked]<mailto:[email-masked]>>; Michael Koster <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]> WG <[email-masked]<mailto:[email-masked]>>
Subject: RE: [core] draft-ietf-core-resource-directory

Best regards
Matthias

> To: Michael Koster <[email-masked]<mailto:[email-masked]>>; Kovatsch Matthias
> <[email-masked]<mailto:[email-masked]>>
> Cc: [email-masked]<mailto:[email-masked]> WG <[email-masked]<mailto:[email-masked]>>
> To: Kovatsch Matthias <[email-masked]<mailto:[email-masked]>>
> Cc: [email-masked]<mailto:[email-masked]> WG <[email-masked]<mailto:[email-masked]>>
> > <[email-masked]<mailto:[email-masked]>>
> wrote:
> >
> > Hi Michael
> >
> [email-masked]<mailto:[email-masked]>

---

From: "Kovatsch Matthias" <[email-masked]>
Date: Fri, 20 May 2016 16:20:45 +0000

When only relying on the RD for such a resolution, there might be a problem with expressing both the authority name and the socket address: The RD basically returns URIs, which can only carry either. The additional information would need to go into a link attribute...

Ciao
Matthias

From: Subramaniam, Ravi [mailto:[email-masked]]
Sent: Freitag, 20. Mai 2016 18:17
To: Kovatsch Matthias <[email-masked]>; Michael Koster <[email-masked]>
Cc: [email-masked] WG <[email-masked]>
Subject: RE: [core] draft-ietf-core-resource-directory

Hi Matthias,

Ravi

Ciao
Matthias

-------- Original message --------
From: "Subramaniam, Ravi" <[email-masked]<mailto:[email-masked]>>
Date: 5/19/16 19:34 (GMT+01:00)
To: Kovatsch Matthias <[email-masked]<mailto:[email-masked]>>, Michael Koster <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked] WG<mailto:[email-masked]%20WG>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [core] draft-ietf-core-resource-directory

Hi Matthias,

Please see inline ...

Ravi

-----Original Message-----
From: Kovatsch Matthias [mailto:[email-masked]]
Sent: Thursday, May 19, 2016 10:22 AM
To: Subramaniam, Ravi <[email-masked]<mailto:[email-masked]>>; Michael Koster <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]> WG <[email-masked]<mailto:[email-masked]>>
Subject: RE: [core] draft-ietf-core-resource-directory

Best regards
Matthias

---

From: "Subramaniam, Ravi" <[email-masked]>
Date: Fri, 20 May 2016 16:44:50 +0000

Matthias,

Yes, IMO, there are 3 approaches:

1.     Link attribute in the same link

2.    Separate links (endpoints as resources)

3.    Wellknown endpoint resource on RD for ep lookups.

2 is more flexible but requires additional setup interactions.

Basically try to use the available CoRE paradigms for endpoint discovery (and optimize discovery). DNS has been around and useful but technically it is a different system and something that has to be deployed/available along with CoRE implementations.

Ravi

Sent: Friday, May 20, 2016 9:21 AM

Ciao
Matthias

To: Kovatsch Matthias <[email-masked]<mailto:[email-masked]>>; Michael Koster <[email-masked]<mailto:[email-masked]>>

Hi Matthias,

Ravi

Ciao
Matthias

-------- Original message --------
From: "Subramaniam, Ravi" <[email-masked]<mailto:[email-masked]>>
Date: 5/19/16 19:34 (GMT+01:00)
To: Kovatsch Matthias <[email-masked]<mailto:[email-masked]>>, Michael Koster <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked] WG<mailto:[email-masked]%20WG>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [core] draft-ietf-core-resource-directory

Hi Matthias,

Please see inline ...

Ravi

-----Original Message-----
From: Kovatsch Matthias [mailto:[email-masked]]
Sent: Thursday, May 19, 2016 10:22 AM
To: Subramaniam, Ravi <[email-masked]<mailto:[email-masked]>>; Michael Koster <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]> WG <[email-masked]<mailto:[email-masked]>>
Subject: RE: [core] draft-ietf-core-resource-directory

Best regards
Matthias

---

From: "Kovatsch Matthias" <[email-masked]>
Date: Fri, 20 May 2016 16:53:32 +0000

I understood it is about resolving the authority name/UUID/... in a URI to the socket address. When this is handled by the RD and not an external service (e.g., DNS), the RD has a problem to encode this in its responses, the link lists. The latter are URI based, so either the URI has the name/UUID/... which has the information for vhosts (e.g., fill the Uri-Host option), but not the transport layer address or the URI has the transport layer address in the authority field, but then lacks the name/UUID/... for multiplexing virtual endpoints behind the same transport layer address.

Maybe you just need the resolve feature from RD, but not the vhost support. There are use cases for both behaviors of the RD, so we should look into a way to accommodate both explicitly, so there will not be issues depending on which RD implementation on picks...

Ciao
Matthias

Sent: Freitag, 20. Mai 2016 18:45

Matthias,

Ravi

Ciao
Matthias

Hi Matthias,

Ravi

Ciao
Matthias

-------- Original message --------
From: "Subramaniam, Ravi" <[email-masked]<mailto:[email-masked]>>
Date: 5/19/16 19:34 (GMT+01:00)
To: Kovatsch Matthias <[email-masked]<mailto:[email-masked]>>, Michael Koster <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked] WG<mailto:[email-masked]%20WG>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [core] draft-ietf-core-resource-directory

Hi Matthias,

Please see inline ...

Ravi

-----Original Message-----
From: Kovatsch Matthias [mailto:[email-masked]]
Sent: Thursday, May 19, 2016 10:22 AM
To: Subramaniam, Ravi <[email-masked]<mailto:[email-masked]>>; Michael Koster <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]> WG <[email-masked]<mailto:[email-masked]>>
Subject: RE: [core] draft-ietf-core-resource-directory

Best regards
Matthias

---

From: "Subramaniam, Ravi" <[email-masked]>
Date: Fri, 20 May 2016 17:05:35 +0000

Hi Matthias,

Maybe I was not clear - the RD does not have to "resolve" the UUID - it would not be possible when there are multiple endpoints. Also to allow the demuxing with Authority for a single endpoint, the UUID has to be in the URI - which means the endpoint info has to be separated and will be used in the messaging layer.

The difference is that instead of "looking up UUID as a hostname" in DNS, the ideas is to make a request to a well-known "endpoint" lookup resource on the RD using UUID as a filter (well ... there are a few ways to do this here).

In either case of DNS or RD, it is a two-step process. But if one uses RD there are opportunities to optimize which will not be possible with an external system like DNS. (I guess I got into the optimization before I was clear with the base model :) )

Makes sense?

Ravi

Sent: Friday, May 20, 2016 9:54 AM

Ciao
Matthias

Matthias,

Ravi

Ciao
Matthias

Hi Matthias,

Ravi

Ciao
Matthias

-------- Original message --------
From: "Subramaniam, Ravi" <[email-masked]<mailto:[email-masked]>>
Date: 5/19/16 19:34 (GMT+01:00)
To: Kovatsch Matthias <[email-masked]<mailto:[email-masked]>>, Michael Koster <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked] WG<mailto:[email-masked]%20WG>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [core] draft-ietf-core-resource-directory

Hi Matthias,

Please see inline ...

Ravi

-----Original Message-----
From: Kovatsch Matthias [mailto:[email-masked]]
Sent: Thursday, May 19, 2016 10:22 AM
To: Subramaniam, Ravi <[email-masked]<mailto:[email-masked]>>; Michael Koster <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]> WG <[email-masked]<mailto:[email-masked]>>
Subject: RE: [core] draft-ietf-core-resource-directory

Best regards
Matthias

---

From: "Kovatsch Matthias" <[email-masked]>
Date: Fri, 20 May 2016 17:10:09 +0000

Hi Ravi

I think I got you now:

There is a look-up interface in RD (probably the ep lookup to finally make it more useful :P) that will return a list of two or more URIs, where one has the UUID in the authority field and the remaining carry the transport-layer specific addresses (and usually there are two URIs only in this list...).

Best wishes
Matthias

Sent: Freitag, 20. Mai 2016 19:06

Hi Matthias,

Makes sense?

Ravi

Ciao
Matthias

Matthias,

Ravi

Ciao
Matthias

Hi Matthias,

Ravi

Ciao
Matthias

-------- Original message --------
From: "Subramaniam, Ravi" <[email-masked]<mailto:[email-masked]>>
Date: 5/19/16 19:34 (GMT+01:00)
To: Kovatsch Matthias <[email-masked]<mailto:[email-masked]>>, Michael Koster <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked] WG<mailto:[email-masked]%20WG>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [core] draft-ietf-core-resource-directory

Hi Matthias,

Please see inline ...

Ravi

-----Original Message-----
From: Kovatsch Matthias [mailto:[email-masked]]
Sent: Thursday, May 19, 2016 10:22 AM
To: Subramaniam, Ravi <[email-masked]<mailto:[email-masked]>>; Michael Koster <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]> WG <[email-masked]<mailto:[email-masked]>>
Subject: RE: [core] draft-ietf-core-resource-directory

Best regards
Matthias

---

From: "Subramaniam, Ravi" <[email-masked]>
Date: Fri, 20 May 2016 17:12:19 +0000

Right - Ravi

Sent: Friday, May 20, 2016 10:10 AM

Hi Ravi

I think I got you now:

Best wishes
Matthias

Hi Matthias,

Makes sense?

Ravi

Ciao
Matthias

Matthias,

Ravi

Ciao
Matthias

Hi Matthias,

Ravi

Ciao
Matthias

-------- Original message --------
From: "Subramaniam, Ravi" <[email-masked]<mailto:[email-masked]>>
Date: 5/19/16 19:34 (GMT+01:00)
To: Kovatsch Matthias <[email-masked]<mailto:[email-masked]>>, Michael Koster <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked] WG<mailto:[email-masked]%20WG>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [core] draft-ietf-core-resource-directory

Hi Matthias,

Please see inline ...

Ravi

-----Original Message-----
From: Kovatsch Matthias [mailto:[email-masked]]
Sent: Thursday, May 19, 2016 10:22 AM
To: Subramaniam, Ravi <[email-masked]<mailto:[email-masked]>>; Michael Koster <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]> WG <[email-masked]<mailto:[email-masked]>>
Subject: RE: [core] draft-ietf-core-resource-directory

Best regards
Matthias

---

From: Michael Koster <[email-masked]>
Date: Fri, 20 May 2016 10:25:46 -0700

+1

Michael

PS we may be able to define some sort of link structure and "rel" value to register links that describe the endpoints along with the resources, as was mentioned earlier. It could be a supplementary feature to the internally stored registration parameters that are set using query parameters. This could be another way to filter endpoint parameters in addition to the ep lookup function.

> On May 20, 2016, at 10:12 AM, Subramaniam, Ravi <[email-masked]> wrote:
> 
> Right - Ravi
>  
>  <>From: Kovatsch Matthias [mailto:[email-masked]] 
> There is a look-up interface in RD (probably the ep lookup to finally make it more useful :P) that will return a list of two or more URIs, where one has the UUID in the authority field and the remaining carry the transport-layer specific addresses (and usually there are two URIs only in this list…).
>  
> Best wishes
> Matthias
>  
>  
> From: Subramaniam, Ravi [mailto:[email-masked] <mailto:[email-masked]>] 
> To: Kovatsch Matthias <[email-masked] <mailto:[email-masked]>>; Michael Koster <[email-masked] <mailto:[email-masked]>>
> Cc: [email-masked] <mailto:[email-masked]> WG <[email-masked] <mailto:[email-masked]>>
> Maybe I was not clear – the RD does not have to “resolve” the UUID – it would not be possible when there are multiple endpoints. Also to allow the demuxing with Authority for a single endpoint, the UUID has to be in the URI – which means the endpoint info has to be separated and will be used in the messaging layer.
>  
> The difference is that instead of “looking up UUID as a hostname” in DNS, the ideas is to make a request to a well-known “endpoint” lookup resource on the RD using UUID as a filter (well … there are a few ways to do this here).
>  
> In either case of DNS or RD, it is a two-step process. But if one uses RD there are opportunities to optimize which will not be possible with an external system like DNS. (I guess I got into the optimization before I was clear with the base model J )
>  
> Makes sense?
>  
> Ravi
>  
> From: Kovatsch Matthias [mailto:[email-masked] <mailto:[email-masked]>] 
> To: Subramaniam, Ravi <[email-masked] <mailto:[email-masked]>>; Michael Koster <[email-masked] <mailto:[email-masked]>>
> Cc: [email-masked] <mailto:[email-masked]> WG <[email-masked] <mailto:[email-masked]>>
> I understood it is about resolving the authority name/UUID/… in a URI to the socket address. When this is handled by the RD and not an external service (e.g., DNS), the RD has a problem to encode this in its responses, the link lists. The latter are URI based, so either the URI has the name/UUID/… which has the information for vhosts (e.g., fill the Uri-Host option), but not the transport layer address or the URI has the transport layer address in the authority field, but then lacks the name/UUID/… for multiplexing virtual endpoints behind the same transport layer address.
>  
> Maybe you just need the resolve feature from RD, but not the vhost support. There are use cases for both behaviors of the RD, so we should look into a way to accommodate both explicitly, so there will not be issues depending on which RD implementation on picks…
>  
> Ciao
> Matthias
>  
> From: Subramaniam, Ravi [mailto:[email-masked] <mailto:[email-masked]>] 
> To: Kovatsch Matthias <[email-masked] <mailto:[email-masked]>>; Michael Koster <[email-masked] <mailto:[email-masked]>>
> Cc: [email-masked] <mailto:[email-masked]> WG <[email-masked] <mailto:[email-masked]>>
> From: Kovatsch Matthias [mailto:[email-masked] <mailto:[email-masked]>] 
> To: Subramaniam, Ravi <[email-masked] <mailto:[email-masked]>>; Michael Koster <[email-masked] <mailto:[email-masked]>>
> Cc: [email-masked] <mailto:[email-masked]> WG <[email-masked] <mailto:[email-masked]>>
> When only relying on the RD for such a resolution, there might be a problem with expressing both the authority name and the socket address: The RD basically returns URIs, which can only carry either. The additional information would need to go into a link attribute…
>  
> Ciao
> Matthias
>  
> From: Subramaniam, Ravi [mailto:[email-masked] <mailto:[email-masked]>] 
> To: Kovatsch Matthias <[email-masked] <mailto:[email-masked]>>; Michael Koster <[email-masked] <mailto:[email-masked]>>
> Cc: [email-masked] <mailto:[email-masked]> WG <[email-masked] <mailto:[email-masked]>>
> Thanks yes, that would be great. (Actually the “DNS-like” service can be similar to Resource discovery and so a separate service is not necessary).
>  
> BTW: end point information can also be returned as part of Resource retrieval – so the resolution can be “piggybacked” even though endpoint information is distinct. This depends on how the endpoint information is represented. Need to read the draft to make sure that this method is also possible.
>  
> Ravi
>  
> From: Kovatsch Matthias [mailto:[email-masked] <mailto:[email-masked]>] 
> To: Subramaniam, Ravi <[email-masked] <mailto:[email-masked]>>; Michael Koster <[email-masked] <mailto:[email-masked]>>
> Cc: [email-masked] <mailto:[email-masked]> WG <[email-masked] <mailto:[email-masked]>>
> From: "Subramaniam, Ravi" <[email-masked] <mailto:[email-masked]>>
> To: Kovatsch Matthias <[email-masked] <mailto:[email-masked]>>, Michael Koster <[email-masked] <mailto:[email-masked]>>
> Cc: "[email-masked] WG <mailto:[email-masked]%20WG>" <[email-masked] <mailto:[email-masked]>>
> From: Kovatsch Matthias [mailto:[email-masked] <mailto:[email-masked]>] 
> To: Subramaniam, Ravi <[email-masked] <mailto:[email-masked]>>; Michael Koster <[email-masked] <mailto:[email-masked]>>
> Cc: [email-masked] <mailto:[email-masked]> WG <[email-masked] <mailto:[email-masked]>>
> > From: Subramaniam, Ravi [mailto:[email-masked] <mailto:[email-masked]>]
> > To: Michael Koster <[email-masked] <mailto:[email-masked]>>; Kovatsch Matthias 
> > <[email-masked] <mailto:[email-masked]>>
> > Cc: [email-masked] <mailto:[email-masked]> WG <[email-masked] <mailto:[email-masked]>>
> > From: core [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Michael Koster
> > To: Kovatsch Matthias <[email-masked] <mailto:[email-masked]>>
> > Cc: [email-masked] <mailto:[email-masked]> WG <[email-masked] <mailto:[email-masked]>>
> > > <[email-masked] <mailto:[email-masked]>>
> > wrote:
> > >
> > > Hi Michael
> > >
> > [email-masked] <mailto:[email-masked]>
> > https://www.ietf.org/mailman/listinfo/core <https://www.ietf.org/mailman/listinfo/core>

---

From: "Subramaniam, Ravi" <[email-masked]>
Date: Fri, 20 May 2016 17:39:34 +0000

Hi Michael,

I have used that approach as an option for OCF - if you guys are working on endpoint link attributes and rel name (I used "ep" which may be lame), we could compare notes so that our proposals are sync'd out of the gate.

Ravi Subramaniam
Principal Engineer
Intel - (408) 765-3566

On May 20, 2016, at 10:25 AM, Michael Koster <[email-masked]<mailto:[email-masked]>> wrote:

+1

Michael

On May 20, 2016, at 10:12 AM, Subramaniam, Ravi <[email-masked]<mailto:[email-masked]>> wrote:

Right - Ravi

Hi Ravi

I think I got you now:

Best wishes
Matthias

Hi Matthias,

Makes sense?

Ravi

Ciao
Matthias

Matthias,

Ravi

Ciao
Matthias

Hi Matthias,

Ravi

Ciao
Matthias

-------- Original message --------
From: "Subramaniam, Ravi" <[email-masked]<mailto:[email-masked]>>
Date: 5/19/16 19:34 (GMT+01:00)
To: Kovatsch Matthias <[email-masked]<mailto:[email-masked]>>, Michael Koster <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked] WG<mailto:[email-masked]%20WG>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [core] draft-ietf-core-resource-directory

Hi Matthias,

Please see inline ...

Ravi

-----Original Message-----
From: Kovatsch Matthias [mailto:[email-masked]]
Sent: Thursday, May 19, 2016 10:22 AM
To: Subramaniam, Ravi <[email-masked]<mailto:[email-masked]>>; Michael Koster <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]> WG <[email-masked]<mailto:[email-masked]>>
Subject: RE: [core] draft-ietf-core-resource-directory

Best regards
Matthias

---

From: Michael Koster <[email-masked]>
Date: Fri, 20 May 2016 10:58:18 -0700

Hi Ravi,

I just went over the endpoint stuff I could find and it looks like the use case could be described as late binding of transfer protocols. Resolution of the protocol URL amounts to dereferencing a binding. It seems like each endpoint will contain the same resources, and only differ by transfer scheme and layers below that. Is this accurate?

In CoRE RD, that binding of OCF UUID based URL to bound protocol URL could be done in more than one way. 

1. You could register an "RD endpoint" for each transfer layer scheme available (with associated transport, network, etc.) and give them all a common endpoint type ID, maybe using the UUID, but unique endpoint names. All resource links would need to be registered under each endpoint. Then you could lookup endpoints by using the UUID as endpoint type, and this could return endpoint URIs, which you could then use to lookup resources. You could also use this registration scheme to do resource lookup by UUID, which will return a list full URLs to resources in all endpoints that matches the lookup, including the endpoint scheme, authority, and port. The client can then select the appropriate link by scheme.

2. Another way is to register the resources using the UUID as endpoint name, and register a link describing each protocol binding. The lookup would need to be done separately for bindings and resources, but the client could remember it's favorite protocol URI for each endpoint and not need to look it up each time.

I imagine there are other ways; what do you think?

Michael

> On May 20, 2016, at 10:39 AM, Subramaniam, Ravi <[email-masked]> wrote:
> 
> Hi Michael,
> 
> On May 20, 2016, at 10:25 AM, Michael Koster <[email-masked] <mailto:[email-masked]>> wrote:
> 
>> +1
>> 
>> Michael
>> 
>>> On May 20, 2016, at 10:12 AM, Subramaniam, Ravi <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>> Right - Ravi
>>>  
>>>  <>From: Kovatsch Matthias [mailto:[email-masked] <mailto:[email-masked]>]

---

From: "Subramaniam, Ravi" <[email-masked]>
Date: Fri, 20 May 2016 18:51:25 +0000

Hi Michael,

Please see inline ...

Ravi Subramaniam
Principal Engineer
Intel - (408) 765-3566

On May 20, 2016, at 10:58 AM, Michael Koster <[email-masked]<mailto:[email-masked]>> wrote:

Hi Ravi,

I just went over the endpoint stuff I could find and it looks like the use case could be described as late binding of transfer protocols. Resolution of the protocol URL amounts to dereferencing a binding. It seems like each endpoint will contain the same resources, and only differ by transfer scheme and layers below that. Is this accurate?
[Ravi : ] Yes for the most part - the difference may be from how each of us view "endpoint". In my view each endpoint may contain different resources but a set of resources may share same set of endpoints.

1. You could register an "RD endpoint" for each transfer layer scheme available (with associated transport, network, etc.) and give them all a common endpoint type ID, maybe using the UUID, but unique endpoint names. All resource links would need to be registered under each endpoint. Then you could lookup endpoints by using the UUID as endpoint type, and this could return endpoint URIs, which you could then use to lookup resources. You could also use this registration scheme to do resource lookup by UUID, which will return a list full URLs to resources in all endpoints that matches the lookup, including the endpoint scheme, authority, and port. The client can then select the appropriate link by scheme.
[Ravi :] this is similar to the server resolution scheme I mentioned in passing. As I see it, the are issues with this approach since endpoint information can change over the lifetime of a resource the book keeping is harder and there is storage implication. Also the servers view may not be a client view (eg firewall)

2. Another way is to register the resources using the UUID as endpoint name, and register a link describing each protocol binding. The lookup would need to be done separately for bindings and resources, but the client could remember it's favorite protocol URI for each endpoint and not need to look it up each time.
[Ravi : ] This is the option being used because not only does it allow the URI to be stable but also allows a use of different endpoint dynamically. This allows endpoint info to be provided separately and possibly different sources while server only provides the stable URI. There may be issues here too and it may be that I am too biased to see :-)

I imagine there are other ways; what do you think?
The RD could be a hybrid too

Michael

On May 20, 2016, at 10:39 AM, Subramaniam, Ravi <[email-masked]<mailto:[email-masked]>> wrote:

Hi Michael,

Ravi Subramaniam
Principal Engineer
Intel - (408) 765-3566

+1

Michael

Right - Ravi

Hi Ravi

I think I got you now:

Best wishes
Matthias

Hi Matthias,

Makes sense?

Ravi

Ciao
Matthias

Matthias,

Ravi

Ciao
Matthias

Hi Matthias,

Ravi

Ciao
Matthias

-------- Original message --------
From: "Subramaniam, Ravi" <[email-masked]<mailto:[email-masked]>>
Date: 5/19/16 19:34 (GMT+01:00)
To: Kovatsch Matthias <[email-masked]<mailto:[email-masked]>>, Michael Koster <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked] WG<mailto:[email-masked]%20WG>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [core] draft-ietf-core-resource-directory

Hi Matthias,

Please see inline ...

Ravi

-----Original Message-----
From: Kovatsch Matthias [mailto:[email-masked]]
Sent: Thursday, May 19, 2016 10:22 AM
To: Subramaniam, Ravi <[email-masked]<mailto:[email-masked]>>; Michael Koster <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]> WG <[email-masked]<mailto:[email-masked]>>
Subject: RE: [core] draft-ietf-core-resource-directory

Best regards
Matthias