[
https://issues.apache.org/jira/browse/AVRO-641?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Doug Cutting updated AVRO-641:
------------------------------
Attachment: AVRO-641.patch
Thanks for the detailed review, Aaron!
> The SaslSocketTransceiver.transceive(...) method declaration should have a
> space after the return type.
Fixed.
> In SaslSocketTransceiver, it seems like saslResponsePiggybacked can
> potentially be read before its initialized. Should probably explicitly set a
> default value.
Java fields, unlike variables, always have a default value. The default for a
boolean is false.
> Spelling in the "Overview" section of the protocol spec: "suceeds" ->
> "succeeds".
Fixed.
> In the "Negotiation" section of the protocol spec: I don't believe the
> mechanism name can be UTF-8. I'm pretty sure mechanism names are required to
> be a subset of ASCII, as defined in http://www.faqs.org/rfcs/rfc4422.html.
> Further, the mechanism name can only be up to 20 characters, so no need for
> 4-bytes to specify the length of the mechanism name.
UTF-8 and ASCII encode the characters permitted in mechanism names identically.
But specifying UTF-8 is confusing, so I've removed that from the document.
I slightly prefer to leave the mechansim length at 4-bytes, since it simplifies
implementation. At each step in the negotiation one always reads the status
byte followed by a 4-byte length-prefixed payload. (In the case of the START
message, one must read an additional, similarly formatted payload.) So not only
would I need to add new methods to read and write one-byte length-prefixed
strings, but I'd also have to separately read the payload of each message. If
we really wanted to minimize bytes, we might also change the length of a FAIL
message to be two bytes. Should I worry more about these wasted bytes?
> In the "Negotiation" section of the protocol spec: Is it really the case that
> "Once EITHER [capitalization mine] the client or server send a COMPLETE
> message then negotiation has completed successfully" ? i.e. should it not be
> "both" ?
I believe that when one side sends COMPLETE the other side does not respond,
that a single COMPLETE terminates negotiation. I think that's what I've
implemented. Without this, implementing an anonymous mechanism without adding
a round-trip would be trickier.
> In the "Session Data" section of the protocol spec: You make reference to
> "steps 5 and 6" but there is no previous numbering of steps in the protocol.
Fixed. I wonder where that strange text came from?
> add SASL to socket transport
> ----------------------------
>
> Key: AVRO-641
> URL: https://issues.apache.org/jira/browse/AVRO-641
> Project: Avro
> Issue Type: New Feature
> Components: java
> Reporter: Doug Cutting
> Assignee: Doug Cutting
> Fix For: 1.4.1
>
> Attachments: AVRO-641.patch, AVRO-641.patch, AVRO-641.patch,
> AVRO-641.patch, AVRO-641.patch, AVRO-641.patch, AVRO-641.patch
>
>
> Java's socket transport is non-standard (not in the Avro spec) but might
> serve as a prototype of a future standard transport (AVRO-341).
> It would be useful to extend it to support SASL-based authentication and
> encryption.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
