[Standards] Jingle File Transfer (XEP-0234) uses NonNegativeInteger instead of UnsignedLong.
jonas at wielicki.name
Tue Jul 18 11:14:05 UTC 2017
On Dienstag, 18. Juli 2017 12:16:02 CEST Florian Schmaus wrote:
> On 17.07.2017 14:45, Jonas Wielicki wrote:
> > On Montag, 17. Juli 2017 13:29:02 CEST Paul Schaub wrote:
> >> This is a very minor issue, but XEP-0234 uses positiveInteger as
> >> attribute type for the FileTransferElementType's size attribute.
> >> positiveInteger contains all positive numbers except '0', which requires
> >> implementers to choose eg. the BigInteger class to represent that value.
> > Or an implementation could reject the transfer with a policy-violation or
> > similar error in case it cannot handle files or numbers that big.
> IMHO unbounded values should be avoided in protocols when possible.
In general I agree. In this specific case, however, I don’t see much harm if
it is explicitly specified that (a) the number is unbounded and (b) the peer
is free to reject the request if the number is out of the range supported by
the peers implementation. Everything else would be an unnecessary artificial
restriction which can be easily avoided.
> >> I think unsignedLong would fit better here. Same goes for the
> >> fileTransferRangeType's offset value, which is currently
> >> nonNegativeInteger. This limits the size of the transferred file to 4GB
> >> or less.
> > Please let us not do that in the standard. I know, nobody will ever
> > transfer 4 GiB files over XMPP---until someone does. The size should at
> > least be 64 bits
> xs:unsignedLong is 64 bits .
If consensus for my suggestion cannot be reached, I’m fine with unsigned 64
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: This is a digitally signed message part.
More information about the Standards