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.
>>
>>
>