RadioVIS Specification V1.1.0-DRAFT (2012-04)

[Ben Poor]

Dear All,

I have prepared the latest draft release of the RadioVIS Specification v1.1.0 (2012-04) for your approval. This can be found at:

http://radiodns.org/wp-content/uploads/2012/03/RVIS01-v1.1.0-draft.pdf

This combines all changes within previous drafts as well as recent discussions, highlights include:

* Change of topic construction for IP-bearers

* Clarification on topic construction for FM and DAB (avoiding confusion with ECC)

* Ability for HTTP transport response to send back multiple RadioVIS messages

* Removal of initial idea for support 'static' services (i.e. radiovis-static)

* Change of HTTP transport Message ID header response from Mandatory to Optional

The first two resulted from explicit feedback, whereas the second two result from different pieces of feedback and development of ideas.

It became apparent that the initial idea for a 'static' RadioVIS service was not a good fit, and so the idea has been developed slightly within the existing framework such that the functionality can be supported without adding another transport.

The functionality can be supported through the HTTP transport, and ensuring that a response from the service provider does not return a Message ID. This is a signal to the client that further requests must not be made. In this way, a service provider can set up a static service with a static file on a webserver.

I've also checked through the document again to make sure that the language used is appropriate, but certainly the bulk of changes is within Section 5, HTTP transport.

I'm aiming to get this specification, if acceptable, into the next RadioDNS GA for approval so please could you send any feedback/questions as soon as possible.

If there is a lack of sustained objection to this draft by end of Friday 30th March 2012 (UTC), then this specification will be forwarded as our official proposal to the RadioDNS board.

I'd like to have everyones support behind this, if possible, so if you've read it and agree then feel free to drop me an email.

Kind Regards,

Ben

ben....@radiodns.org

[Pete Redhead]

Hi Ben,

The spec looks good to me. Just one thing to pick up on - it's probably just a typo.

At the end of section 4.3, talking about STOMP frames it says:
The body of a MESSAGE frame contains the message bodies specific to the RadioVIS protocol defined in Section 6.

Should this actually say "defined in Section 3"?

Thanks,
Pete

[Pete Redhead]

Hi Ben / group,

I've been working on an implementation of the Vis-HTTP server, to see how the proposed spec will work in practice. Based on my findings, I have a few suggestions:

Section 5.1 - HTTP Request

I feel it would be a good idea to stipulate what the acceptable characters are in the json-p callback parameter. Currently it is listed as string, but not all characters are valid in javascript function names.
Perhaps the specification could reference section 7.6 of ECMA-262 to indicate what is acceptable.

Section 5.2 - JSON Response

When the JSON response contains multiple frames (ie returns an array rather than a single message) there is no maximum size of response defined. Whilst I appreciate that the point of the specification is not to stipulate how the protocol should be implemented, I forsee a risk that a rouge client could make a request using a very old message ID. The resulting document that is returned could be of a considerable size, and possibly provide a way to carry out a DoS attack on a server.
Additionally, if there is no sanity check on the size of the array / amount of data returned, a situation could, in theory, arise where several megabytes of data are being sent to a mobile client.

I also feel that the set of messages that are to be returned could be better defined. As I understand it, for a single requested topic:
No last-id specified: Return the latest message for the topic.
Last-id specified and matches most recent message for topic: Keep connection open and wait for next message.
Last-id specified but is different from last message: Send messsages that have been transmitted since that particular ID was sent.
If the last-id does not correspond to a message on that topic (or the server no longer has a reference of it), I assume that this would be treated as no last-id transmitted.

Best wishes,
Pete

[Ben Poor]

Thanks for the feedback Pete, in original order:

1. Section 5.1

I agree, we should refer to the ECMAScript specification for guidelines on Identifier names, although this should be assumed to following standard Javascript guidelines anyway.

Will insert a reference to this section for further information on acceptable Identifier naming.

2. Section 5.2

Yes - whats more meaningful a number or a size? I'm thinking either max. 16 frames or 50kB response.

Will look at the rules regarding ID again, as you suggest

[Pete Redhead]

16 frames or 50kB sounds sensible to me. Although I feel a hardware manufacturer would be better placed to comment on the size of data returned as memory requirements are of more concern than say for a mobile phone client app.

Pete