Application protocol URI

[Ka...@bmw.de]

Hi,
an issue concerning the URI: Right now, only the transport protocol is part of the URI (e.g. tcp:://...).

Shouldn't there be a hint to the application protocol, e.g. etch_tcp:://...  which seems more appropriate? The question arises e.g. with the UDP extensions, which could provide different application semantics like "reliable_etch_udp" or "maybe_etch_udp". These protocols could use different headers, so it could be needed to distinguish between different application protocols in the URI.

Best regards,
Kay Weckemann
BMW Group
Research and Technology

RE: Application protocol URI

[Holger Grandy <Ho...@bmw-carit.de>]

Hi, 

> ... 
> udp://host:port?UdpTransport.reliable=true&UdpTransport.encrption=aes25
> 6&UdpTransport.encryptionKey=somesecretkey
> ...

I would also suggest to use URL parameters for things like encryption scheme
or reliability patterns. The Protocol scheme in the URI would be overloaded 
when trying to encoding all possible options into it. We also do have some 
of those parameters already (e.g. Packetizer.maxPacketSize)
I would not use UdpTransport.encryption, but PacketEncryption.Algorithm
or something like that, because UDP and Security are two separate things.

>     * reliability (delivery guaranty)
>     * encryption
>     * tamper resistance (mac)
>     * session / connection management
>     * authentication
>
> anyone got any more?

Looks good from my point of view. Kay, what options did you think of?

Cheers,
Holger

> On 11/3/2010 4:36 AM, Kay.Weckemann@bmw.de wrote:
> > Hi,
> > an issue concerning the URI: Right now, only the transport protocol
> is part of the URI (e.g. tcp:://...).
> >
> > Shouldn't there be a hint to the application protocol, e.g.
> etch_tcp:://...  which seems more appropriate? The question arises e.g.
> with the UDP extensions, which could provide different application
> semantics like "reliable_etch_udp" or "maybe_etch_udp". These protocols
> could use different headers, so it could be needed to distinguish
> between different application protocols in the URI.
> >
> > Best regards,
> > Kay Weckemann
> > BMW Group
> > Research and Technology
> >

Re: Application protocol URI

[scott comer <we...@mac.com>]

well, "tcp:..." doesn't entirely mean tcp, but rather is just a 
conveniently picked name which is bound to a transport stack factory.

tls is tcp with tls stream encryption.

tcp2 is tcp as well, but with a selector scheme for managing sockets. 
tls2 is tcp2 with tls encryption.

your uri scheme is up to you, you can call it udp or something else. 
there is possibly a length limitation on schemes. and we can always 
argue about it later, so don't let it drag you down. mnemonic is ok, but 
i wouldn't go overboard. you can also use uri query terms to select options:

udp://host:port?UdpTransport.reliable=true&UdpTransport.encrption=aes256&UdpTransport.encryptionKey=somesecretkey

there are several main option groups:

    * reliability (delivery guaranty)
    * encryption
    * tamper resistance (mac)
    * session / connection management
    * authentication

anyone got any more?

mainly, both ends have to have more or less the same scheme and options 
selected. the best practice in a complex setup is to use the name 
service to abstract uris.

have fun!

scott out

On 11/3/2010 4:36 AM, Kay.Weckemann@bmw.de wrote:
> Hi,
> an issue concerning the URI: Right now, only the transport protocol is part of the URI (e.g. tcp:://...).
>
> Shouldn't there be a hint to the application protocol, e.g. etch_tcp:://...  which seems more appropriate? The question arises e.g. with the UDP extensions, which could provide different application semantics like "reliable_etch_udp" or "maybe_etch_udp". These protocols could use different headers, so it could be needed to distinguish between different application protocols in the URI.
>
> Best regards,
> Kay Weckemann
> BMW Group
> Research and Technology
>