Proposal: Extension of RadioDNS ServiceIdentifier parameter

[Ben Poor]

Dear All,

As part of my final preparation of the latest draft I have had a request to look again at the restrictions places on the RadioDNS ServiceIdentifier signalled for each service within the XSI document.

From the current definition (Section 3.3.4, radiodns), two attributes are specified on the <radiodns> element: fqdn, serviceIdentifier

Parameters	Description	Value	Status
fqdn	RadioDNS Authoritative FQDN The Authoritative FQDN used in the discovery of RadioDNS applications when no broadcast parameters are available.	Valid domain	mandatory
serviceIdentifier	RadioDNS Service Identifier The Service Identifier used in the discovery of RadioDNS applications when no broadcast parameters are available.	Maximum 16 lower case characters in the range [a-z][0-9]	mandatory

The proposal would be to change the definition of the serviceIdentifier attribute to:

Maximum 64 lower case URI-compliant characters. 

The exact phrase is to be developed, but would possible correspond to the list of allowable characters in RFC3896 (http://tools.ietf.org/html/rfc3986#page-11).

The field was originally defined before the other attribute (FQDN) was added and before further thought into how these could be used to identify services, signal lookup parameters over IP-streams (detailed in the RadioDNS specification), and provide cross-over with existing functionality (e.g. using these parameters in the icy-url field as part of a Shoutcast IP stream for both RadioDNS signalling purposes *and* the for signalling the Stream website).

I can see no reason to continue restricting the field to its original definition and thus support its extension in this way.

One complicating factor is that the same field is also defined within the RadioDNS specification, and so will need to be redefined here as well. Should there be a lack of objection for this proposal, I will put this to the RadioDNS Steering Board for inclusion in the next version of the RadioDNS specification.

Can I ask you all to consider whether this change would cause any issues. In particular, whether any device manufacturers foresee issues in widening the scope and length of characters in this field. Note that this change will not cause any existing implementations to become non-compliant.

Many thanks,

Ben

[Robin Cooksey]

Hi Ben,

 

Thank you for raising this.

 

I think this proposed change would also affect the current RadioVIS spec as well – it uses the ServiceIdentifier in section 2.5 (IP-delivered audio service) to construct the topic name for IP services.  That explicitly defines the ServiceIdentifier with the same constraints as the RadioDNS spec (max of 16 lower case characters).  So, obviously any changes would need to be reflected in an update to the RadioVIS specification too.

 

 

I’m slightly unclear about exactly which characters you’re proposing would be allowed from RFC 3986?  Is it any character mentioned in it, or just unreserved characters?  I.e. is the intention to allow actual URLs to be used, or just to allow some other non-alphanumeric characters to be used?

 

The potential issue that I can see is where the ServiceIdentifier is used.  E.g. in RadioVIS it’s used in a topic name, which itself is used in the Stomp protocol, and also as an HTTP query parameter.  I haven’t thought this all through yet, but presumably the implication is that a client may need to percent encode parts of the topic name, if any URI character is allowed?

There’s a similar potential issue for RadioEPG – for looking up XSI documents given the service details for an IP delivered stream, the ServiceIdentifier forms part of the path in the URI for the XSI document, in section 4.1.5 of the RadioEPG v1.1 spec.

 

Another aspect to this is other places where the ServiceIdentifier can be obtained from – in addition to the RadioEPG XSI document.  For example, RDNS01 V1.0.0 specifies (in section 6.2) various ways that the FQDN and ServiceIdentifier can be embedded in an IP stream (e.g. using a Shoutcast icy-url header).  Are there any other constraints imposed here, or encoding that would become necessary?

 

As I say, I haven’t fully thought through the implications of this but I thought I’d raise the possible issue.  I think this will become the first time that RadioDNS service parameters could contain non-alphanumeric or ‘.’ characters – meaning that they might need some form of escaping or quoting whenever they’re used in various places (e.g. RadioVIS topics, radioEPG URLs etc).  I think perhaps we should consider whether that’s a good idea – or whether it will be simpler in the long term to keep RadioDNS service parameters as alphanumeric and ‘.’ characters only.

 

To be clear – it’s widening the scope of allowed characters that I suspect might be problematic, not increasing the maximum length of the ServiceIdentifier field.

 

 

Also, when you say “Note that this change will not cause any existing implementations to become non-compliant.”; presumably you’re referring to “broadcaster-side” implementations – i.e. implementations which define and make available these ServiceIdentifiers?  (I.e. as the change is to relax the constraints, any ServiceIdentifier which is already valid and in use today would continue to be valid.).

Obviously the same doesn’t apply to any client implementation which has been written to use the ServiceIdentifier – if it assumes (or specifically validates) the constraints on the ServiceIdentifier, it would then become non-compliant if these constraints are relaxed.  This also applies to the change in length, as well as relaxing the constraints on allowed characters.

 

Best regards,

Robin

 

 

 

 

 

--
You received this message because you are subscribed to the Google Groups "RadioEPG developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to radioepg-develo...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Ben Poor]

Hi Robin,

Thanks for your reply. Unfortunately my comments on compliance were poorly worded - they do not take into account any clients that have reasonably written their implementation based on the current restrictions to this field. Any extension to the field with thus cause them to break.

As you mention, the ServiceIdentifier is the 'glue' that holds together RadioDNS Lookup for non-Broadcast bearers in ALL the RadioDNS specifications. Its use in an IP-stream is somewhat dependant on the stream format/protocol, and so the current definition of this field was given as a 'lowest common denominator', i.e. something we could be pretty sure was usable across the majority of streaming formats/protocols. Extending this would increase the chance that we could not make it work for additional formats/protocols.

Even extending the maximum length of the field would require coordination across all 3 existing ratified specifications (RadioDNS, RadioVIS, RadioEPG).

With all this in mind, it appears as though changing the definition of the field would be too disruptive for the benefits it would bring. 

If anyone disagrees with this conclusion, please do reply.

Thanks,

Ben

To unsubscribe from this group and stop receiving emails from it, send an email to radioepg-developers+unsub...@googlegroups.com.