Ken Giusti commented on PROTON-136:


Re: the api naming - yes, I totally agree that "link" and "session" are bad 
choices for this new api.  And now that you mention it - yes, we certainly can 
preserve the 'old' api and just extend the api model a bit to support a top 
level "container" for SSL connections (and thus, SSL sessions).

Not 100% sure I like the "config" name - there may be other non-config-y things 
we could do with the top level object, like query it for state or statistics, 
which really isn't "config" like.   And I don't want to use 'context', which is 
perfect but conflicts with the existing conventions for user-supplied context.

How about "domain"?

In any case, let's leave the existing API in place, and extend it as follows:

// new top level object - container for related SSL connections:

pn_ssl_domain_t *pn_ssl_domain( pn_ssl_mode_t );
pn_ssl_domain_free( pn_ssl_domain_t * );

// create a new SSL connection "owned" by the domain:

pn_ssl_t *pn_ssl_new( pn_ssl_domain_t *, pn_transport_t *)
pn_ssl_free( pn_ssl_t * )  // no change here

// new domain-based configuration api:
int pn_ssl_domain_set_peer_authentication(....)

// new object to represent the state of a single SSL connection

pn_ssl_state_t *pn_ssl_get_state( pn_ssl_t *);
int pn_ssl_resume_state( pn_ssl_t *, pn_ssl_state_t * );
void pn_ssl_state_free( pn_ssl_state_t * );
bool pn_ssl_state_resumed_ok( pn_ssl_t * )


> Add support for SSL session resumption
> --------------------------------------
>                 Key: PROTON-136
>                 URL: https://issues.apache.org/jira/browse/PROTON-136
>             Project: Qpid Proton
>          Issue Type: New Feature
>          Components: proton-c
>    Affects Versions: 0.3
>            Reporter: Affan Dar
>            Assignee: Ken Giusti
>              Labels: ssl, sslContext, sslresume
> Open SSL supports resumption of SSL sessions which by-pass the heavy SSL 
> handshake process. This is critical for scenarios involving low powered 
> devices especially on cellular data networks where bandwidth is precious.
> It would be great if Proton exposes this ssl resume feature to users. .
> From: rhs [mailto:rschlom...@gmail.com] 
> Sent: Tuesday, November 13, 2012 11:34 AM
> To: Affan Dar
> Cc: David Ingham
> Subject: Re: SSL session resumption
> On Tue, Nov 13, 2012 at 8:05 PM, Affan Dar <affan...@microsoft.com> wrote:
> >>Serializing/restoring the whole session state for the messenger will work 
> >>for the scenario I think.
> Ok, let's start with this step then. I'm open to providing something finer 
> grained if there is a need, but my preference is to keep it simple for the 
> moment.
> >>One more thing, RFC 5077 has another flavor of session resumption which 
> >>openssl supports (original >>implemented as RFC 4057 back in 2007 I think). 
> >>This allows us to resume sessions without carrying state >>on the server 
> >>side which as you can imagine is a big deal for service vendors. Probably 
> >>there is no API >>level impact if messenger handles the session state 
> >>itself but just wanted to put this on your radar.
> Ok, good to know.
> Could one of you file a JIRA for this upstream? I'm trying to get things a 
> little more organized on the process front and keep everything centralized in 
> JIRA. ;-)
> --Rafael

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Reply via email to