- From: Francois Daoust <fd@w3.org>
- Date: Thu, 06 Nov 2008 14:32:38 +0100
- To: Jo Rabin <jrabin@mtld.mobi>
- CC: public-bpwg-ct <public-bpwg-ct@w3.org>
Yes. That's what I mean. Which makes me think that if we mention it, this could be part of the diagram explaining which proxies are in scope, as resolved in: http://www.w3.org/2008/10/20-bpwg-minutes.html#item34 Just an addendum. The STI Web service can in theory be used by any of the actors of the delivery chain, i.e: 1/ by the content provider, and that's the example I gave 2/ by a CT proxy, why not. 3/ by a user agent receiving for instance something encoded in a format it doesn't directly support. In any case, from an external point of view, the use of a STI service is transparent, in the control of the box that uses it, and as such out of scope of what we are talking about. Francois. Jo Rabin wrote: > From what you are saying, Francois, we'd consider this server side > adaptation, in that it is in the control of the content provider, and > hence out of scope of what we are talking about? > > Jo > > On 06/11/2008 10:58, Francois Daoust wrote: >> >> Hi, >> >> LC-2051 mentions the work of the OMA on a Standard Transcoding >> Interface (STI) and recommends we take a look at it: >> >> http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-ct-guidelines-20080801/2051 >> >> >> I took ACTION-868 to review OMA STI. Here's my report. >> >> >> In short >> -------- >> No overlap between OMA STI and the CT Guidelines (apart from the fact >> that they're both talking about transcoding, that is). >> The only possible change we may do is to add a reference to the OMA >> STI in the Scope for Future Work along with POWDER. >> >> >> Version of OMA STI >> ------------------ >> I tried to download the latest version of the specifications, but the >> links on the following page are broken: >> http://www.openmobilealliance.org/Technical/release_program/sti_v10.aspx >> >> If anyone knows how to retrieve the latest version, I'm interested. I >> reviewed the 20050704 release. I don't know whether it is still >> accurate, but the overall objectives, requirements and spirit of the >> specifications surely haven't changed. >> >> >> Description of OMA STI >> ---------------------- >> As explained in the Last Call comment, the OMA STI specification is >> meant for an architecture where a Content Provider requests >> transformation to a third-party transcoding service. Transformation >> operations are typically intended to convert and adjust media content >> (audio, pictures, videos) between different formats so that they may >> be served to a large number of devices. OMA STI is thus a Web services >> interface whose typical work flow for Web browsing could be described >> with the following use case: >> 1. a Content Provider receives a request from an end-user on some >> audio file. >> 2. the Content Provider usually serves its audio files as Ogg Vorbis >> files. It detects that the end-user device does not support this >> format, and sends a request to some transcoding server to convert the >> audio file to the MP3 format. >> 3. the transcoding server performs the conversion and returns the >> result to the Content Provider. >> 4. the Content Provider returns the converted audio file to the >> end-user. >> >> OMA STI provides ways for the Content Provider to send multiple >> transcoding requests (called jobs) at once. This can be useful when >> you want the result to fit within a given size limit: all images of a >> page could thus be sent to the transcoding service with a "please make >> sure the sum of the sizes of all the converted images does not exceed >> 50KB" directive for instance. >> >> The MORFEO project web site describes a few implementations of the >> specification: >> >> http://forge.morfeo-project.org/wiki_en/index.php/Transcoding_Module_Evolution#Implementations >> >> >> >> Relationship with the CT Guidelines >> ----------------------------------- >> There is no direct overlap between OMA STI and the Content >> Transformation Guidelines. >> The guidelines cover the case where the transcoding platform is not a >> third-party entity but a non-transparent proxy that intercepts all >> HTTP messages between the Content Provider and the end-user. >> >> As such, there is not much we can extract from the interface >> specification. >> >> I can't think of any incompatibility between OMA STI and the CT >> guidelines either. In other words, for the purpose of the CT >> guidelines, a Content Provider that makes use of a third-party >> transcoding service is still a Content Provider. >> >> One thing that may be noted is that OMA STI defines a kind of >> vocabulary to describe transformation operations, and it could be >> integrated in a potential future work on the vocabulary we envision >> and that could be used in POWDER. Mentioning OMA STI in the Scope for >> Future Work appendix along with POWDER might be a good idea. >> >> >> Francois. >> >> >
Received on Thursday, 6 November 2008 13:33:15 UTC