On Thu, 2015-06-11 at 13:40 +0100, Gordon Sim wrote:
> On 06/11/2015 01:11 PM, aconway wrote:
> > I disagree. An empty string is a perfectly legal value for a 
> > string. If
> > the spec wants to assign special meaning to particular values of a
> > property that needs to be stated. Of course, like you, I personally
> > would not use an empty string as an identifier but as an 
> > implementor of
> > an inter-operable spec I think we have to take the large view: 
> > *any*
> > legal value of a parameter has to be considered equal unless the 
> > spec
> > clearly states otherwise.
> If a name field is populated with an empty string, that to me is the 
> same as not supplying a name. An empty string is a legal encoding, 
> but 
> in my view it does not supply a value at all. (It is not like say 0 
> which may be the default but is clearly a value in its own right).

It is exactly like 0, a perfectly legal value that is often abused to
mean something special. "" is a legal string literal in every language
I know of. It can be used as a key in a map or hash table. It can be
compared with other strings. There is no string operation in any
language I know that will throw NotAString if you apply it to "".

> However, from the practical point of view...

This is very practical. Interoperability is about agreeing on a type
system. A "type" defines a range of legal values. The AMQP type system
includes empty string and 0-length binaries as legal values for those
types. We absolutely cannot treat any legal value in an exceptional way
unless that is clearly mandated by the spec.

> [...]
> > Quote me the spec, this is a mater of law not opinion ;)
> I suspect that the sending of an empty string for a multi-frame 
> message 
> is entirely unintentional on the part of Apollo. I suspect it is a 
> bug 
> in Apollo or in the proton-j version/path it uses. That should be 
> confirmed and an appropriate JIRA raised

That's fine for Apollo but irrelevant for proton. The first law of
interoperability is "be strict with what you send, be forgiving with
what you receive." To me that means that we should never *send* an
empty delivery tag, but we should accept one unless the spec clearly
states that it is illegal for anyone to ever send one. I see no such
clear statement.

> Proton-c should also not crash on receiving an empty (or null) 
> delivery 
> id. Beyond that I'm not overly concerned how it handles the empty 
> string 
> case.

Reply via email to