Comments Received on FIMS v1.0 7 November 2011

Comments received on FIMS 1.0 IBM - 4 Oct EBU - 8 Oct Cube-Tec International - 25 Oct HR - 25 Oct, 26 Oct, 3 Nov IRT - 28 Oct IBM/Bloomberg - 31 Oct Quantel - 31 Oct Sony - 1 Nov BBC - 1 Nov 2

IBM - Majeed Arni 4 Oct 11 1.Please add figure number for all figures. 2.In section (first figure there) and section last figure. - Instead of manageJob, I think it should be queryJob to get the status. 1.In , description of notifyAt (tell what WSDL/operation does the URI need satisfy). I think it should be TransferMediaNotification. 2. In the WSDL/XS I see TransferMediaNotification but not defined or described in the PDF spec file. 3

EBU - Jean-Pierre Evain 8 Oct 11 1.Add a section in the specification with the namespaces used in XSD and WSDL files. Define evolutionary namespace structure as new namespaces will be needed for e.g. phase 2. 2.technical metadata only allows the description of basic/simple business media objects - the proposal is to encapsulate this technical metadata in a "businessObject" and associated "part" to allow the description of parts / segments of content as well as technical parameters along specific timelines 4

Cube-Tec - Jörg Houpert/Denis Pingin 25 Oct 11 Within FIMS 1.0 we would like to describe (in terms of metadata) a media container that has two or more video (or audio) tracks where each track has its own format (e.g. DTS + AC3 + PCM). The videoTrack (or audioTrack) data type does currently not allow to specify such a format. The cardinality of videoFormat or audioFormat is [0..1]. It would be just sufficient to changes it to [0..*] In EBUCore it is already designed this way [0..*] 5

HR (1) - Mirko Zimmer 25 Oct 11 - Chapter I think, the Media Bus is a product-specific extension and it is not a required component for an architecture implementation?! As part of the spec it suggests, that you need this kind of component for AV/file exchange (in addition to the transfer service?) or that the "middleware" is not just a middleware, but also responsible for active file exchange (in competition to the transfer service?). But this is more or less a matter of taste?! - Chapter : This is an essential pattern for the FIMS services. The FIMS specific way of implementing this communication pattern would be more traceable if there is a pointer to chapter 9.4 and a reference/hint to the notification binding of each service wsdl?! - Chapter 9: Media Service Communication: It would be very useful if the spec could contain example service requests, particulary for the service interface types. 6

HR (2) - Mirko Zimmer 25 Oct 11 - Chapter 9.3.1: Transfer Service Interface. Basically I think, that this service definition is too abstract in V1.0! Beside of the job and the bmo parameters, the transfer request contains the transfer profile only, which defines just a transferAtom URI for the destination. All the transfer (static and dynamic) configuration parameters must be filled in the "any" section and therefore it is not specified. This allows us to do almost anything with the transfer interface and it will be more or less a "vendor specific" thing. Switching to a new service implementation will be not so easy. It will be difficult to define the responsibility boundaries to other services too. Our understanding of the transfer service is to offer file exchange capabilities between servers with standard protocol support as described in chapter , thus the transfer service differs from other services like a source management service (extended source information service) or an export service (maybe this two new services are phase 2 candidates?). 7

HR (3) - Mirko Zimmer 25 Oct 11 With the idea of substituting our existing, self developed transfer service interface with a FIMS compliant transfer interface some concrete questions: - What means "[....] accessing media files" in the first paragraph of chapter 9.3.1? Beyond the transfer facility of files what kind of functionality should be supported? - How can we pass connection information for source and destination locations to the service, ftp user and password for example. It is possible to encode this in the authority part of the URI, but this is not the preferred way. - Sometimes, it is necessary, that a file must be renamed during the transfer. For this case the transform service defines the outputFileNamePattern, but it is not part of the transfer request?! - How can we provide transfer mode parameters like move or copy mode. Another use case is to distinguish between fxp transfer or piped ftp transfer. Because of some security restrictions, fxp is not always allowed (for external delivery for example). - Should the transfer service support a "local" move or copy mode for moving files inside a location? Or is it part of the Source Information Service? For a transfer request the source and destination locations are equal in this case. 8

HR (4) - Mirko Zimmer 26 Oct 11 There is another issue concerning the callback pattern and the MediaResponseType.: The MediaResponseType is a pretty complex xml schema. For example in case of a transfer notification my soapUi produces a complex xml instance from the schema, see below. The spec says, that this callback has to be sent to the Service Consumer by the service! The service consumer must be able to "understand" this callback with all optional or mandatory fields and combinations of the fields! On the other side, the service capability for this callback must be well documented. Not all service implementors will support all fields?! If it is not clearly described, you can create a strong dependency between the service implementor and service consumer. Possibly, the interoperability between service implementors will be decreased?! An alternative could be a stronger separation of job status information (operation info) and media object information (bmo, bmresultmap) in the reponse capabiliy of a service. For example, the transfer notification (the callback) could contain only the operation information: job with id xy has finished with state 'Completed'. If the service consumer is interested in more media object related information, he can call the already defined TransferMediaStatusBinding/queryJob interface in a next step. We use this way of separating job and information data in our quality control service adapter. The VIO process sends a job to the quality control service. The job is acknowledged. After completion, the service sends a callback with pure job state information (check successfull, no errors for example) back to the platform. After this, the process instance uses a method like "get report" to read the complete report. In my opinion, the service capability concerning the response data can be better described by the service provider in this way. The service consumer has the freedom of choice to use the queryJob interface for additional data or not. The drawback is the second call to the service of course. 9

HR (5) - Mirko Zimmer 3 Nov 11 Asynchronous request response pattern: The BaseRequestType defines the notifyAt parameter (AsyncEndpointType), which should contain the callback address (chapter ). Additional to the callback address we need a user/password information to authorize the callback client (the service). At the moment, there is no option for that and we must configure a default user/password for the service implementation. Maybe there should be such an option in the BaseRequest/AsyncEndpointType? On the other side, putting the (uncrypted) user/password information in each request could be a bigger security issue?! 10

IRT (1) - Matthias Elser 28 Oct 11 Errors: [Page 12 of 122, Chapter , Paragraph 3] "This corresponds to SLA in a conventional IT-based SOA system and is referred to as M-SLA. Because the detailed specifications of M-SLA need to be harmonized with SLA, this will need to be need to be discussed by the FIMS Task Force at a later date in accordance with SLA developments." [Page 26 of 122, Chapter , Sequence Diagram] *response := manageJob("status", jobID), should be queryJob [Page 29 of 122, Chapter 8.1.3, Sequence Diagram] *responseWithFault := manageJob("status", jobID), should be queryJob [Page 120 of 122, Chapter Appendix 1.1, Clause 2] "As described in Section 8.2.2, a pipelined media service within a service can be realized using profiles. Error! Reference source not found. shows an example of extended pofile usage where two Capture (Transform) profiles are used to create main stream essence (J2K + MXF) and proxy essence (AVC + MP4) with AV Process." 11

IRT (2) - Matthias Elser 28 Oct 11 Remarks: [Page 18 of 122, Chapter 6.2.2] The ListFilterType should be able to filter on ALL JobStatusCodes separately (queued, running, paused, completed, canceled, terminated, failed, cleaned, unknown) instead of grouping to "queued", "active", "finished" and "failed". According to the annotation in baseMediaService-V1_0_0.xsd, the JobStatusCode "canceled" is not in any of the four grouping. [Page 26 of 122, Chapter 8.1.4] How does the framework allow retry of failed services? How does the framework allow the definition of compensation mechanism ? Maybe this should be described a bit more detailed. 12

IBM/Bloomberg - Peter Guglielmino 31 Oct 11 We have compiled a set of suggested changes and additions to the technical metadata that we would like the FIMS members to review and comment on. - See: proposed fims output technical metadata modifications V2.docx - See: EBU_CORE_FIMS_TechnicalMetadataType_Bloomberg_EBU_rev.zip 13

Quantel (1) - Richard Cartwright 31 Oct 11 The following comments about FIMS are mainly from the perspective of a detailed review of the XSDs provided rather than the specification document. As such, they are concerned with technical constraints imposed on an embodiment of FIMS by the architecture of its specification that would limit current or future specifications rather than on whether the specification is fit for its business purpose. As such, these are fundamental architectural concerns that may be difficult to address pragmatically in the short term. However, I believe the group needs to be aware of their existence and significance as this work is intended as a framework platform. First of all, the good bits: 1) An extensible means to describe services. 2) A clean state model. 14

Quantel (2) - Richard Cartwright 31 Oct 11 At a high level: 1)FIMS lacks overriding architectural principles, such as "a single authoritative source for any item of metadata", and as such messages are overloaded with too much information. I believe that the specification encourages metadata to travel with command and control messages in an RPC-style on the assumption that the only way a target system will known about a source system's metadata is through the metadata contained in the message. This is a tight coupling that is brittle to metadata changes (multiple copies of data everywhere) and will lead to all kinds of problems where architectures where every island is sent everything just in case it is needed. Far better to have clean command and control interfaces and separate, loosely-coupled metadata services. 2) A clean data model is not clearly specified or embodied anywhere (e.g. UML class diagram). This makes implementation of a Model-View-Controller application or RESTful set of resource- oriented services hard. In fact, it is my view that lack of a clear data model is over complicating the specification and XSDs and makes them difficult to extend. FIMS has a few primary entities (Job, Queue, BMObject, BMFolder, Metadata, ServiceCapability) that could be brought out in a simple model. Data model analysis would call into question why jobs have tasks rather than jobs being composed of other jobs? 3) Some concepts are mixed together - what is state and what is a command (e.g. asking for a Queue's status vs starting and stopping it) mixes view and control. A view of a folder structure is often a tree hierarchy (view) but a filing system data model is rarely implemented that way... a child points at its parents. As another example of this, a BMObject may be described by many different metadata sets depending on the application's it is used in (contracts vs presentation). 15

Quantel (3) - Richard Cartwright 31 Oct 11 Some comments on the XML schema: Why use xs:sequence everywhere? What about xs:all that allows elements to appear in any order? Why use attributes for numerator and denominator values? A pattern " / " would be less verbose? In fact, why use attributes at all? You could achieve everything in FIMS with just element values and this is a much more consistent approach. The time type prohibits the use of 30 or 36 hour clocks, common in scheduling applications where the broadcast day starts at 6am. Best to either use strict SMPTE 12M timecodes limited to 23:59:59:29 combined with a date or allow for values up to 99:59:59:29. For true interoperability, UIDs need to be much more tightly defined than just strings... e.g. GUIDs/UUIDs and UMIDS 16

Sony - Toshiaki Kojima 1 Nov 11 17

BBC (1) - Peter Brightwell 1 Nov 11 Document needs an introduction that provides some hand-holding, else it can come across as somewhat impenetrable. This could be the developer guide that's been discussed, and it needs to have some simple examples, perhaps an overview of the data model. How simple can FIMS really be? Can we give a minimal example showing a sequence of HTTP requests and responses? Support proposed separation of document into general, base and service as proposed in recent s from Sony and Avid. Terms such as "ESB" and "Media Bus" would seem to suggest a particular approach to implementation, but I don't think that's what we're trying to tell people. This could be helped with the minimal examples. Clarity on how FIMS can support RESTful interaction style, with decoupling of command logic from metadata. There appears to be quite a RPC-like nature to many parts of FIMS (esp in section 9.2), which would complicate development in an MVC environment (which is what we are currently doing). See also Richard Cartwright's recent comments on this, and my of Sept 29th. 18

BBC (2) - Peter Brightwell 1 Nov 11 Section 7 could be rearranged so that the explanation of what it's about (in 7.2) comes first, then going into the details of the registry and description documents. In 7.1.1, can anything be said about a convention for the initial HTTP GET, or some other method to help bootstrap discovery? Also the '/' before the '?' in two of the examples should probably omitted. Although it's good that some specific standard transfer classes are enumerated in , something should be said about extensibility, in case the reader to thinks that their (possibly proprietary) transfer technology couldn't be using for a FIMS-mediated transfer. Also perhaps something should be said about "plug-and-play" interoperability, eg a baseline profile that we can expect implementations to support. (Or is that being unrealistic, it doesn't seem to have worked for DLNA...). Also in this section, the part "Multiple entries...considered authorative" needs explanation. Section 7.2.5: is this unfinished? 19

BBC (3) - Peter Brightwell 1 Nov 11 Section 8.1.9: checking the status isn't really a task as such. I think Richard made a similar, but better, comment about this. Section 8.2.1: "ServiceDefinedTime type: the time defined by a service" - needs more explanation! Later the doc talks about event-based information, but this needs clarifying. Section 8.2.2: Atoms is defined here, but used several times earlier in the doc - this could be tackled by reorganisation? The examples in this section would be useful earlier on. Section 9.3.1: This talks about a "target agent" but the spec doesn't explain what this is or its context. (I think this is inherited language from SMPTE ST 2032, where it has a specific meaning for point-to-point file deliveries.) Section : This says the profile "may specify how [the media format] is produced." How do this happen (or does this really mean specifying the technical parameters of what is produced)? Appendix 1: Missing reference 20