Minutes of the call 9 February 2015

DAISY Online Delivery Protocol (DODP) Refresh call

Monday 9 February 2015 11am UTC

Introductions

Dave Gunn (Chair & Scribe), Claudio Montalban, Fredrik Schill, Hiro Fujimori, Takuro Shiroki, Jelle Martijn Kok, Per Sennels, Edmar Schut, Dominic Labbé.

Regrets:

Actions:

Action Dominic: provide further content for the guidance topics identified.

Action All: encourage partner organisations who are not active on the working group to submit feedback to the public review.

Topics for discussion:

Public Review – feedback update

Dave – this slot is for us to look at the feedback which has come in from the public review, and to talk through some of those items.

Claudio – The feedback I’d like to explore is initially from Humanware (https://github.com/daisy/DAISY-Online-Refresh/issues/51) point 4.2.1, there seems to be a misinterpretation here that the wording indicates that a service may only attempt to connect to the service discovery system when it is not already connected to a service. There is an apparent contradiction on the following line when it says the reading system should be able to look for services through the UI. The intention of the phrase here is to say if a reading system is not configured to a service, its default operation when going online should be to present the user with the service discovery mechanism. Whereas if the reading system is configured to a service, its default behaviour should be to connect to that service, but present access to the service discovery mechanism through another section of the UI. I don’t think the phrase precludes this, it simply says: "When a Reading System connects to the internet and is not configured to connect to a Service Provider, it may request a list of available compliant services from the Daisy Consortium website." It doesn’t say it may not do it in other cases, but we could reword it to make this clearer.

Fredrik – I think you phrased it well yourself just a moment ago, so if we could write that down I think that would cover it. We don’t need to specify the UI, just that it is ok to contact at a later stage, it just may not be the first thing that appears to the user.

Dave – so would it be good to update the text in the issue tracker and go from there?

Claudio – we will have to update the text on the document, the question is what wording would be better than the wording already there? If you are happy with what I said we can transcribe that and put that in, but I think there may be more elegant ways to put it.

Dominic – this came from one of my team, and I think what you just said would be more than enough to clarify.

Claudio – the next point of feedback is on an enhancement to the service discovery mechanism, we add the ability to add a URL to an audio sample to the service name, aimed at reading systems without TTS, or service names in languages other than the device language. This would be a new feature which we haven’t previously discussed. Will there really be DAISY Online systems without TTS?

Dominic – even if a system has TTS the name may not be pronounced correctly, a Russian library pronounced by a Spanish TTS would probably be as bad as not having TTS at all. I have a problem with podcasts and internet radio stations which do not pronounce correctly, and sometimes need to be corrected using special correctors. The idea of having a recording would get around this.

Claudio – support for TTS is probably a bigger question and would involve a lot more changes that we haven’t talked about. A lot of the functions of the protocol rely on TTS in order to convey things to a client, then we have correct pronunciations – though XML phonetics or voice XML tags. I understand that more reading systems do not currently support that. I would be interested in hearing from Shinano Kenshi how they resolve this in Japanese TTS.

Takuro – for correct pronunciation control of the TTS we tried several ways, however it is difficult to control completely, so we still rely on a quality TTS and when it is wrong we try to correct it, but it is difficult to support phonetic correction for the TTS engine. The TTS maker has a way to correct the pronunciation, but this is very dependent on the TTS. Using the audio label could be the right solution, and supporting the audio label could also be possible for the non-TTS devices however one concern about audio libraries is slow response for the user interface.

Fredrik – I agree, there are different alphabets for the phonetic translation, so it depends on the vendor of the TTS. If we look at the new type we created here which is called Service, which contains the information on the service, the first property is Name which is a string. We could simply change that to a Label, then it is up to the service if they want to provide an audio label to enhance the presentation of their service, or if they want to rely on the reading systems. All we need to do is change the string to label.

Dominic – and I think it makes sense, as asking libraries to create phonetics which sound good in every language just doesn’t make sense. I think a possibility for an audio label is good if people are not using it you can try your best with the TTS, but at least there is an option for libraries like Icelandic where there are not many TTS available on devices I think it’s an easy provision.

Claudio – considering this has the potential to slow down the calls which it retrieves voice samples, potentially for a large number of libraries, do we think this is a change worth doing?

Dominic – I think it is. If I were to implement that on a service knowing that services don’t come and go every day, just sometimes changing name when the library changes name, I would use a cached system and keep the MP3 in my player at all times, just making changes when needed, so I don’t think it would slow down anything. You can do discovery say once every 6 months, it’s not something you do every day to check the papers.

Fredrik – I think this could be a good change.

Dave – can we just check if there are any objections to us moving forward with this approach?

No objections recorded.

Claudio – the next point is around Latitude/Longitude. Does anyone know of a relevant standard for referencing this information in XML so we can enhance the documentation?

Dominic – I think we could look at the Google format (KML) used to exchange position, is probably the closest thing to a de facto standard. Many people use these files to exchange positional information, I don’t think there is an international standard, but this way seems to be working fine. Personally I don’t see the geolocation working well, especially if you are on the border of a country your nearest library may be in a different country, but if it is helpful for others let’s do it.

Jelle Martijn – the W3C has defined a standard for geometric points http://www.w3.org/2003/01/geo/ I just googled it, but it looks like we could use this one.

Dave – so if there is a W3C standard which is appropriate we should use that, otherwise we can explore the Google solution.

Claudio – the next point is about “is there going to be a standard test performed by the DAISY Consortium to validate the reader before adding it to the list, if so it would be helpful to document the standard test”. This is similar to another point about what constitutes an approved reading system and standard validation tests. I never envisaged a standard test for compliance. It would certainly be a useful thing to have, but we would need to write those guidelines and there would need to be a need from the Consortium to be able to execute those guidelines, and that would require resource for every reading system or service. I’m not sure if we have time to take this to the Consortium to see if this is something they would undertake, perhaps Dave can comment? The original intention was simply to say that whoever is responsible for maintaining the list should simple validate that the company producing the reading system or service is genuine, not a standard test but a simple check.

Dominic – in the past we had the DAISY OK testing which was interesting but never went anywhere because nobody had the will or the power to organise such testing, so in the same way I don’t think we can do much with this. I think the spec mentioned something like certify which gives the impression that there is a mechanism behind it.

Dave – my gut instinct is that the Consortium doesn’t have the resources to be testing reading system or services for compliance, but we may be able to find a middle ground where as a working group we come up with a test from which people can self-certify?

Dominic – writing a spec for a test is a large task, it was tough when it was for a CD based player and we never came up with something which was useful, and I think here with transactions for different error cases etc. etc. it’s a very complex task, I’m not sure we want to go there. I think if we make that clear in the spec whoever is reading that will not expect a specification for testing, and know not to rely on any certification or testing for them.

Dave – I think that makes a lot of sense.

Claudio – I also don’t think we have time to write such guidelines, neither will the consortium have resources to execute it. The wording used in the specification was actually “approved reading service” and the question was what constitutes an approved reading system?

Dominic – I think “compliant” is what we need here. At least compliant implies you can be compliant yourself by following all the rules.

Fredrik – compliant is good, both for reading systems and services.

Dave – that seems to make sense, are there any objections to us switching that to compliant?

No objections.

Dominic – everywhere we use something which someone might have to do we could switch that to compliant so any stakeholders know that the need to do their job properly.

Claudio – the next point is around reading system configuration, where originally we had envisaged user credentials being available for the reading system once. So when I inform a reading system that this player belongs to me, those credentials will be passed to that serial number, and once consumed those details are removed from the database. The reason for that was to prevent those credentials from being available, and they only existed for a brief period of time, and one couldn’t go fishing for credentials by spamming a server with lots of serial numbers. Since then we introduced the concept of public keys and encrypting the users data passed to the reading system. The question then becomes, does the additional security measure become irrelevant, should we remove the single configuration option? Or is that still a useful security measure?

Fredrik – I’m not sure if we need to state this in the protocol. I think it should be allowed for the service to do this more than once, but we don’t need to mention it. But from a practical point of view I don’t think any secure system would be able to send back the user credentials for a given reading system, because that would mean the password is stored unencrypted otherwise it would be impossible to return it. So from a practical point of view it should only be for a system to return it once, but for some reason if you need to reset the password it may happen outside the protocol, but perhaps it is too hard to define here it should not be allowed.

Dominic – does the protocol have to tell libraries how long to keep keys available, it’s their business.

Dave – is there a potential security risk here, or have we mitigated that as the changes to the service have developed?

Claudio – it is mitigated not by the fact the keys are encrypted, so the original security concern is not as great as it was before.

Fredrik – the problem we have here now is if a service responds with user credentials for a system which has already been configured, the only way to respond with user credentials is to set new user credentials. It is possible for any new client to connect, claim to be a certain system and get user credentials, and that would reset the actual reading system entitled to those settings. It would not be able to use them, because it wouldn’t have the private key, but it would still be able to destroy the connection for the real reading system. So I think all services should be very careful when responding to this call when a reading system has been configured.

Dominic – what we have to understand is when a machine breaks and gets repaired it gets reconfigured with the same serial number, so in that case there is a genuine case to reauthorize with the same serial number and same everything, just different memory inside that device.

Fredrik – in that case the operator within the service would probably do something, and state that machine needs a reset or something.

Claudio – correct, the flag on the service would be reset back to enable that credential to be resent as it was in the first place.

Dominic – what you said makes sense, but I’m not sure if defining business rules within the protocol is going too far in terms of telling the libraries their job.

Claudio – I don’t think we should use an enforceable word, but perhaps leave it as a suggestion as a recommendation for additional security, unless people want to drop the concept all together as a recommendation. We are not going to compel libraries to implement business rules, but it is sometimes helpful to inform libraries how a business rule may be enforced. This is not intended to be mandatory.

Dominic – I’m fine with a recommendation, as long as it is not binding because that is usually where it created libraries not respecting the spec. As a recommendation if they don’t follow it at least they’re not breaking the rules.

Dave – any objections to us changing that to a recommendation?

No objections recorded.

Claudio – one requirement was brought up which wasn’t discussed before concerning the last modified date located in the contentItem. Currently this is not mandatory in the specification, there is a recommendation that this is made mandatory in order to support when titles are updated after a user has download a copy of the earlier version, a newer last modified date would let the reading system know to update the item. This is probably most useful for newspapers and other time sensitive data where a new edition is released later in the day after the user has downloaded this content. This is a new requirement around modifying this to enable this operation. I wanted to discuss this to see if it should be included in the scope of work for this specification and how it should be done.

Fredrik – I think this is a very good idea. I think we should do this, we had this issue in Sweden and have not really resolved this in a good way when it comes to newspapers. So I think this would be a useful and efficient way for the reading systems to synchronise without having to check all the resources.

Dominic – I concur with Fredrik on this.

Claudio – the only question I have on this is potential impact on the server retrieving the information of the last modified date, as there would be an impact on content resources, any experience on that Fredrik?

Fredrik – we are already behaving in this way, we maintain the last modified date on the contentMeta and when a resource is updated this is updated. We are caching this information so we only update it when there is a modification, and have been running like this for 2 years so it is not a problem. I think it’s very natural because you know from the top down, otherwise you need to go and check for details.

Dominic – I think it’s a very efficient way to do it, and there may be some concern that some players might be polling the library too often, in which case it can be decided if the library operate under modified content or not, which could ease the bandwidth. If you’re doing content like novels you’re probably not modifying them very often, which is very different to a service based on newspapers and magazines.

Claudio – any opposition to changing this to a mandatory requirement?

No objections recorded.

Dave – and Dominic suggested we may benefit from an additional flag?

Dominic – It was just a suggestion which could address a concern about bandwidth if that exists.

Dave – does anyone think there is a case to implement something like this?

Fredrik – I don’t think we should as all libraries somehow need to store metadata on each item, and this could just be one of those, like the title.

Dave – so the proposal is for us not to implement the flag as discussed. Any objections to this approach?

No objections recorded.

Claudio – and I think that is all the principle items of feedback to discuss. There was another question about multiple resources within one package, it is also a new item which has not been discussed before. It basically says “All the resources in the XML should be child of one package node to streamline the parsing that has to be done by the Reading System. The current example in the document repeats the entries for uri, packageURI, packageMimeType and packageSize for every resource in the package. It is inefficient and error prone to repeat such information.” The general idea would be to consolidate that into a single package node, which is an enhancement which hasn’t been discussed so far, but is a good idea and has a lot of merit so I wanted to see if we want to include that enhancement as well.

Fredrik – I think this idea came from us originally, the idea was not to have one package, because the idea we had at MTM was to be able to have one package for text content and then possible another for audio, so the idea was to group content into multiple packages. The case for MTM book service is that it has many requests for all the small text files, and the idea was to group those into one package which would be downloaded as one, and after the audio could be taken one by one. That was the background of this thinking.

Claudio – in that case, is that explanation good for you Dominic?

Dominic – I think so, it was one of my colleagues that put that down, not the actual developer of the system, but that seems to be ok for me. I’ll check with my colleagues, but that seems to be ok for me.

Areas requiring guidance

Dominic – I asked by team as we were reviewing the spec what part they think would require additional non-mandatory information which is not part of the spec, but could enhance the picture so we have good and standardised implementation, and it revolves mostly around workflow. They came up with a few things that might be interesting to get more detail on sequence of operation etc. They came up with:

• Retrieve credentials, which is a new topic and potential for different interpretation.
• Get list of content on server, it would be good to put in some kind of workflow, and hopefully everyone could follow.
• Book download, is much the same would benefit from workflow.
• Check for updated content, something we just touched on, but would be good to include in the guidance something which could include recommendation on frequencies etc so libraries are clear that as soon as something has been updated a reading system is aware, whereas others wanting to avoid such traffic might want checks once an hour, so worthwhile inserting something in there.
• key exchange, the mechanism for exchanging keys.

Dominic – for these 5 I think the spec is clear, but is could be interpreted differently in terms of sequence of operation, so my colleagues were suggesting that we describe the workflow so someone implementing a new system could refer to it if there is a discrepancy.

The last one in the guidance which I think should be there is everything relates to security. I’d say that one third of discussion we had with the previous spec was around people thinking there was some security like expiration, and we need to be clear about what is covered by PDTB2, an if you want to cover something PDTB2 is the way to go for those specific security concerns. I think the spec is much clearer than the previous one, and I think the guidance could simply be a way to help agree on workflows and make player implementations. If we can agree the workflow it would make my life and my developers lives much easier, as well as the libraries lives as well because they would know what to expect from a given player.

Fredrik – Dominic how much text do you think we need to write? Personally I think it would be valuable if we could maintain it within the spec itself so everyone would notice it.

Dominic – my colleagues were expecting not that many words, but descriptive transactions, just to show the information exchange between the system and the server, a typical sequence.

Fredrik – I think we already have the start of that in some places in the spec so would it be possible for you to provide the editors with suggestions to enhance the descriptions that are already there.

Dominic – yes, I’ll talk with my developer who made those suggestions and ask them to give more detail on 1-5. Number 6 probably needs a few generic sentences which need to be clear about security, on expiration and prevention from copying etc. there needs to be a disclaimer somewhere, so I’ll come back with more information on that and ask my developer to expand on this.

Action Dominic: provide further content for the guidance topics identified.

Updates to the specification

Dave – because the week before last both Claudio and Fredrik dropped a lot of other activities in their “day job” to progress the specification, this last week has understandably seen less activity.

Fredrik – basically we decided to have this discussion on the call to address the feedback. We feel we are now in the stage where we discuss the changes we make before we make them. The idea is to implement them and make a new draft after this call.

Next Steps

Dave - There will be an updated version of the specification circulated in the next week for review. This is the parallel version to the one on public review, and I haven’t seen any additional feedback yet, but will be working to raise awareness of that and circulate any feedback which comes in.

Dominic – for feedback I wonder if it would be good it engage directly with libraries not around the table who have an implementation. Swedish and Norwegian libraries are represented but other libraries are not. I know we post on mailing lists and people should read that, but it would be a good idea to reach out to people and see if they have feedback.

Dave – do you have some specific libraries in mind?

Dominic – I know the Finnish library has a DOD implementation, an implementation in Russia. I could look offline and see who I have engaged with over the last couple of years and provide that to you, but the idea is to get as much library engagement as possible, I think that was one flaw in the previous round that some libraries were involve and others were not, especially because the adoption of the new spec is important, we would hope people migrate but if libraries are not paying attention there is a risk we do not cover their stuff and end up doing further rounds.

Dave – I agree and I’m all for encouraging feedback at this point. The DAISY Online mailing list goes to a much wider audience than people who are contributing back, so I think we are reaching those groups, and an article due to be publishing in TechWatch this week will hopefully encourage more feedback. I guess after that we can approach people directly if we think they haven’t engaged at all. Would that be a reasonable approach?

Dominic – I think so, sometimes you need to push for feedback and direct email is always better than a mailing list they may not be actively monitoring.

Dave – I agree completely, and just to address what you mentioned, I believe the Finnish Consortium are actively monitoring the list, they had talked about sending a participant onto the working group but decided that it wasn’t something they needed to do, and were quite happy to watch from the side-lines.

Dominic – the other country was France, but I’ll send you an offline list with different libraries who have been having discussion.

Dave – and I guess there’s no harm in people contacting clients directly to see if there are comments they would like to make.

Dominic – for those we are engaged with we will certainly do that.

Dave – I’m all for drawing attention to it and getting feedback now, because it’s the perfect time.

Action all: encourage partner organisations who are not active on the working group to submit feedback to the public review.

AOB

-

Next regular meeting

Monday 16 February 11am UTC.