[kitten] Fwd: Kitten Digest, Vol 104, Issue 14

[Sam Hartman]

>>>>> "Mayank" == Mayank Upadhyay <mayank+ietf-kitten at google.com> writes:

    Mayank>    Hi Weijun, You point out a legitimate problem, but I want
    Mayank> to understand a couple of assumptions: 1. Why allow only
    Mayank> initSecContext() and acceptSecContext() to have this new
    Mayank> behavior? Imagine a mechanism built on top of TLS which is
    Mayank> renegotiating the session intermixed with actual payload,
    Mayank> and had some error it wanted to communicate to the peer
    Mayank> (e.g., a TLS Alert). Is there any particular reason you'd
    Mayank> like to avoid that scenario?  2. I didn't quite follow the

Hi.
RFC 2743 doesn't allow the abstract wrap or getmic apis to generate an
error token.
I'd object to adding that behavior to the java bindings without adding
it to the abstract API.
So, for the current abstract API, only initSecContext and
acceptSecContext can have this issue.