[nanomsg] Re: UDP & TLS RFCs
- From: Martin Sustrik <sustrik@xxxxxxxxxx>
- To: nanomsg@xxxxxxxxxxxxx
- Date: Tue, 25 Mar 2014 14:21:22 +0100
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 24/03/14 23:41, Alex Elsayed wrote:
> Garrett D'Amore wrote:
>
>> That would not be a terrible way to recast the specs. Although,
>> I think it might come about that we need or want to handle more
>> details than just stream vs datagram semantics on some
>> transports. For example, imagine websocket, where we might want
>> to specify some things that are neither covered by websocket
>> itself nor by the generic SP over STREAM bits. (In particular,
>> for websocket, we might want to have a way to select from
>> different “applications” as part of the early websocket
>> negotiation.)
>
> Oh, for sure - but my point is that by defining based on semantics,
> then you have a base to reference in everything else. Then the only
> thing something protocol-specific needs to do is say "This has X
> semantics, so refer to RFC Y, and we take advantage of special
> property Z like so..."
>
> Plus, that lets you collapse TLS and DTLS' protocol-specific
> portions into a single RFC, because they apply the same _security_
> semantics to SOCK_STREAM and SOCK_DGRAM _transport_ semantics
> respectively.
I was toying with the similar ideas as well, but at the moment we are
not sure what can be considered a common subset of functionality for a
specific subdomain (such as stram-based transprorts). Let's follow the
rule of three and try to extract the common functionality only after
we have three specific cases.
>> I do agree with your earlier idea that tls+tcp:// seems like a
>> good way to specify this scheme. I’ll go ahead and change my
>> implementation to do that.
+1
>> I think we need to include the syntax of these “addresses” as
>> part of the RFCs, so that different applications or
>> implementations can exchange them.
>
> That does make sense.
RFCs typically don't discuss specifics of the API. However, adding a
*suggestion* should be doable:
"In case the implementation needs to refer to this SP protocol mapping
it is preferable that it uses "tls+tcp" name."
Which then raises the issue of the sign '+' which may be valid in URIs
but not in other kinds of identifiers.
Martin
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJTMYLSAAoJENTpVjxCNN9Ye2MH/A3tPWb7mXowy+i5s7s1h/Vj
Eu8vJPYrP2GuCV7TiyShFQSviUoMa+lRzSSPyShqwgtyRlS5ZenV7869DyuqxJhz
SkZgo6hMUMSGnrtVWVD7l/jYDGP7rDC5HyxImMa+3B/U92lrv6n1wSKgVLSdBMNc
15hH+m478lJkVRdqsQdWqWP3NyH59mZTtNaj035bah5gLNhAjWBaddTQYQ4aZxx1
vD2P3od0hJKQRZ/qjJBVutw7UTzxHU98nnAGuSy178OSrN87wDUWOzmJszvU0E8F
btqYxzROv4VoP2Lwi9/YvDAzwrxChULWG26cXt8xft6IcuoMOZ9faZyuIUakdeI=
=X3zB
-----END PGP SIGNATURE-----
Other related posts:
