Shouldn't the AccessEndpoints also contain the protocol

[gunjald]

The access points should have the protocol parameter along with the IP address and port. Or, is there anything I am missing?

[javierlozallu]

In AccessPoints the information retrieved from the Edge Platform is: fqdn:port, ip:port What you are saying is that we need the protocol to complete the URI: protocol:fqdn:port, protocol:ip:port where protocol could be http or https, is this correct?

If that is the case, I totally agree with you

[gunjald]

Yes that is correct. Just going by the standard approaches it could be "ip:port:protocol or fqdn:port:protocol" in my view. Also we may keep protocol at the transport level like TCP or UDP or can also add HTTP/HTTP for application level protocol.

[Kevsy]

I support mandating HTTPS for application endpoints - I suspect they are mandated by the cloud provider in most cases, but worth making it explicit.

Note https indicates "HTTP over TLS", but does not itself specify the version of the application protocol. The version of HTTP (1.1, 2, 3) is negotiated via RFC 7301

Regarding the transport protocol (TCP, UDP, QUIC/UDP etc.): this does not need to be specified, as that is incorporated in the handshake negotiation between client and server.

[gainsley]

HTTP runs over TCP and QUIC runs over UDP. I think it is too limiting to only support HTTP(S). At a minimum we should allow TCP or UDP options. Also specifying HTTPS is an optimization that allows for ingress switching based hostname/path. For example we may want to share multiple applications on the common HTTPS port 443 by switching based on fqdn, so I think it would be useful to also allow HTTPS as one of the protocols.

[Kevsy]

HTTP runs over TCP and QUIC runs over UDP

HTTP runs (over TLS) over TCP, and HTTP runs over QUIC which runs over UDP (with TLS as part of the QUIC 'layer').

Google developed both HTTP/2 (formerly 'SPDY') and QUIC to overcome various limitations of HTTP over TCP, and the latest standard version of HTTP (HTTP/3 ) is a binding of HTTP/2 semantics to QUIC, to make the most of their shared deign principles (binary format, multiplexed streams).

[gunjald]

So shouldnt we just leave it to TCP or UDP which could server most of the use cases?

[Kevsy]

So shouldnt we just leave it to TCP or UDP which could server most of the use cases?

Correct, the API definition does not need to worry about the transport protocol supported by the Application Endpoint.. But including the scheme (e.g. https) in the Application Endpoint URL is good practice.

[gainsley]

So I assume this issue is in reference to the Discovery APIs since it's not clear from the issue summary. Right now I don't see any URL field in the AccessEndpoints model, is the suggestion then to add one or change existing fields to a URL?

Also do we want to support a case where the application is listening on both TCP and UDP (non-http) protocols on the same port, or are we explicitly not allowing that?

Also, do we support applications with their own custom protocols running on top of TCP/UDP? In that case relying on a URL schema may be confusing.

[Kevsy]

So I assume this issue is in reference to the Discovery APIs since it's not clear from the issue summary. Right now I don't see any URL field in the AccessEndpoints model, is the suggestion then to add one or change existing fields to a URL?

I'll let one of the API authors answer that one :)

Also do we want to support a case where the application is listening on both TCP and UDP (non-http) protocols on the same port, or are we explicitly not allowing that?

If it's non-http then there will be no https scheme in the application endpoint, but another scheme (e.g. rtsp etc.). Otherwise this type of discovery and negotiation can be done between client and server, it doesn't need to be covered by the API definition.

Also, do we support applications with their own custom protocols running on top of TCP/UDP? In that case relying on a URL schema may be confusing.

If it's a custom/non-standard URL scheme then it's up to the application developer to make sure there is a supporting client app, which will be configured to opening URLs from that scheme, and have a callback method to handle it.

[gainsley]

If this is the discovery API, my suggestion would be to add the same protocol field that is already present in both the EAM and Federation APIs, as both the discovery port information and federation APIs correspond to the access port information set by the app provider in the EAM APIs. If we switch to using a scheme instead of a protocol both the EAM and Federation APIs would also need to be changed.

[Kevsy]

Since at least one other CAMARA Sub-project (QoD) models an Application Server address, I suggest this discussion be brought to Commonalities , e.g. to include the resource model in CAMARA_common.yaml..

[javierlozallu]

So I assume this issue is in reference to the Discovery APIs since it's not clear from the issue summary. Right now I don't see any URL field in the AccessEndpoints model, is the suggestion then to add one or change existing fields to a URL?

Yes, the AccessEndpoints is an object generated by the Edge Platform, which is returned to the Application Provider when the instantiation is successful using the POST /apps/{appId}/instances and when the Application Provider uses GET /apps/{appId}/instances, in both methods only ip:port is returned so what I understand is that the Application Providers need to also know the protocol to have a complete Endpoint for connectivity as only ip:port might not be enough for a successful connection. This use case assumes that the Endpoint is completely managed by the Edge Platform.

There is another use case/function that can be added and it is similar to what hyperscalers do: Bring your own DNS, in this case we should define a scheme/model for Endpoints that complies with best practices and security.

What do you thing?

Also do we want to support a case where the application is listening on both TCP and UDP (non-http) protocols on the same port, or are we explicitly not allowing that?

About the protocols of the application currently the componentSpec object exists within the AppManifest for the onboarding and contains:

protocol:
type: string
enum:
 - TCP
 - UDP
 - ANY
 description: |
Defines the IP transport communication
protocol i.e., TCP, UDP or ANY

Also, do we support applications with their own custom protocols running on top of TCP/UDP? In that case relying on a URL schema may be confusing.

Maybe the confusion is between app protocol within componentSpec object and endpoint protocol within AccessEndpoints

My understanding of the issue is about protocol://ip:port, protocol://fqdn:port

[javierlozallu]

The Bring Your Own DNS feature may be another Edge Cloud API.

[Kevsy]

My understanding of the issue is about protocol://ip:port, protocol://fqdn:port

It's scheme in the context of a URI, ref RFC 3986 section 3.1 . Ideally we would further avoid ambiguity by referring to transport protocol when we mean TCP, UDP.

So scheme://ipv4:port ,scheme://[ipv6]:port, scheme://fqdn:port .

Note IPv6 addresses should be escaped with [ ] when specifying a port, ref RFC 2732