Issue 5955: Misuse of ComponentPackageReference for Implementation Dependencies (deployment-ftf) Source: Zuehlke Engineering (Mr. Frank Pilhofer, fpilhofer2008(at)gmail.com) Nature: Uncategorized Issue Severity: Summary: The ComponentImplementationDescription class references the ComponentPackageReference class to express dependencies on implementations that have to exist in the target environment. Because of the different semantics, a new class should be introduced instead. Proposed resolution: In section 3.10, "Common Elements", add an ImplementationDepen- dency class as follows: ImplementationDependency Description Expresses a dependency that an implementation has on the target environment. Before this implementation can be deployed, an application of the required type must exist (it must have finished launching) in the target environment. Attributes - requiredType: String The interface type of which an application must exist. Associations No associations. Constraints No constraints. Semantics When launching an application, the ExecutionManager and DomainApplicationManager verify that applications of the required type are already executing. In section 3.4, "Component Data Model", in the Associations section for the ComponentImplementationDescription class, update the type of the dependsOn association to be ImplementationDepen- dency: - dependsOn: ImplementationDependency [*] Expresses a depen- dency on another package; implementations of the referenced interfaces must be deployed in the target environment before this implementation can be deployed. In section 3.8, "Execution Data Model", in the Associations section for the DeploymentPlan class, update the type of the dependsOn association to be ImplementationDependency. Resolution: Revised Text: Actions taken: June 19, 2003: received issue Discussion: End of Annotations:===== Subject: Misuse of ComponentPackageReference for Implementation Dependencies Date: Thu, 19 Jun 2003 09:57:25 -0400 Thread-Topic: Misuse of ComponentPackageReference for Implementation Dependencies Thread-Index: AcM2araWW+E0Qyn1Q0W/LpzOSFT0zA== From: "Pilhofer, Frank" To: Cc: X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id h5JDv0kM002483 This is an issue for the Deployment FTF: The ComponentImplementationDescription class references the ComponentPackageReference class to express dependencies on implementations that have to exist in the target environment. Because of the different semantics, a new class should be introduced instead. Proposed resolution: In section 3.10, "Common Elements", add an ImplementationDepen- dency class as follows: ImplementationDependency Description Expresses a dependency that an implementation has on the target environment. Before this implementation can be deployed, an application of the required type must exist (it must have finished launching) in the target environment. Attributes - requiredType: String The interface type of which an application must exist. Associations No associations. Constraints No constraints. Semantics When launching an application, the ExecutionManager and DomainApplicationManager verify that applications of the required type are already executing. In section 3.4, "Component Data Model", in the Associations section for the ComponentImplementationDescription class, update the type of the dependsOn association to be ImplementationDepen- dency: - dependsOn: ImplementationDependency [*] Expresses a depen- dency on another package; implementations of the referenced interfaces must be deployed in the target environment before this implementation can be deployed. In section 3.8, "Execution Data Model", in the Associations section for the DeploymentPlan class, update the type of the dependsOn association to be ImplementationDependency. From: Subject: Re: Deployment FTF voting (1st poll), closing 20th October 2003 20:00 GMT To: deployment-ftf@omg.org X-Mailer: Lotus Notes Release 5.0.10 March 22, 2002 Date: Fri, 17 Oct 2003 09:54:41 -0500 X-MIMETrack: Serialize by Router on CollinsCRSMTP02/CedarRapids/RockwellCollins(Release 5.0.10 |March 22, 2002) at 10/17/2003 09:54:43 AM Please vote with Yes/No/Abstain for each issue resolution, as detailed in the attachment. Note: A short reason for No votes is mandatory. OMG Issue No: 5953: Yes. OMG Issue No: 5954: Yes. OMG Issue No: 5955: No. - Not sufficient rationale/justification for adding this additonal complexity. No example of problem being solved by adding this new class. OMG Issue No: 5956: Yes. OMG Issue No: 5957: Yes. OMG Issue No: 5958: Yes. OMG Issue No: 5959: Yes. OMG Issue No: 5960: Yes. OMG Issue No: 5961: Yes. OMG Issue No: 5962: Yes. OMG Issue No: 5963: No. - UUID's, Labels, Attributes should not be optional. The Attributes should clearly be required if needed. This solution causes confusion and presents difficulties for tools and applications to anticipate appropriate actions. OMG Issue No: 5964: Yes. OMG Issue No: 5983: Yes. OMG Issue No: 5984: Yes. OMG Issue No: 5985: Yes. OMG Issue No: 5986: Yes. OMG Issue No: 5993: No. Voting No on Issue 6024 requires a different solution for this issue. OMG Issue No: 6024: No. Solution allows/causes XML parsing errors. Need to re-think this solution so that validating parsers work with the XML. OMG Issue No: 6037: Yes. OMG Issue No: 6038: Yes. OMG Issue No: 6041: Yes. OMG Issue No: 6042: Yes. OMG Issue No: 6044: Yes. OMG Issue No: 6046: Yes. OMG Issue No: 6048: Yes. OMG Issue No: 6051: Yes. OMG Issue No: 6052: Yes. ------------------- snip -------------------- Andreas Hoffmann unhofer.de> cc: Subject: Deployment FTF voting (1st poll), closing 20th October 2003 20:00 GMT 10/02/2003 10:07 AM Hi FTF members, this is the first voting for the OMG Deployment FTF. For details on the issue resolutions please refer to the attached document listing all the issue resolutions of this voting. Compared to Tuesday's draft version I have added issue 5962 and moved issues 5993, 6044 and 6052 from "Resolved" to "Duplicate or merged". Anyway, this classification has no impact on the voting. In order to give all FTF members enough time to study the issue resolutions and their impacts on the specification the voting deadline is Monday 20th October, 2003, 20:00 GMT. ------------------- snip -------------------- ** Deployment FTF Voting Poll 1 ** ** Voting Deadline October 20, 2003, 20:00 GMT ** Company: Voter: Regards Andreas ==================================================================== Andreas Hoffmann Fraunhofer FOKUS - Research Institute for Open Communication Systems Kaiserin-Augusta-Allee 31 D - 10589 Berlin Phone: +49 30 3463-7392 Fax: +49 30 3463-8392 Email: andreas.hoffmann@fokus.fraunhofer.de ============= Date: Fri, 17 Oct 2003 17:07:21 -0400 From: Kevin Richardson Organization: The MITRE Corporation X-Mailer: Mozilla 4.79 [en]C-20020130M (Windows NT 5.0; U) X-Accept-Language: en To: deployment-ftf@omg.org Subject: Re: Deployment FTF voting (1st poll), closing 20th October 2003 20:00 GMT One note, please consider indicate the exact subsections where the modifications are to take place (this makes it much easier for me to find the text in the document) OMG Issue No: 5953: Yes OMG Issue No: 5954: Yes OMG Issue No: 5955: No - I'd suggest that the semantics of ComponentPackageReference be made more generic and that the particulars of each association to it be restructured to specify the semantics of how a componentpackagerefernce should be used in that case OMG Issue No: 5956: Yes OMG Issue No: 5957: No - in InstanceDeploymentDescrition, PlanConnectionDescription, PlanPropertyMapping, PackageError there are still references to the label attribute. The resolution should also contain explicit instructions to update the figures. (if these are incorporated - Yes) OMG Issue No: 5958: Yes OMG Issue No: 5959: No - I've got a couple of discussion items before I say yes, 1) In the GenericTransformationRules it states the "an XML schema for persistent storage of metadata" - is it the case that the metadata has to be persistently maintained? 2) The paragraph beginning with "Composition associations in the model..." confuses me to no end, am I just missing something? OMG Issue No: 5960: Yes OMG Issue No: 5961: No - The semantics of CreatePackage need to better explain what distinguishes this operation from InstallPackage - you can probably use some of the text from the summary. It should also explicitly state that it creates the new PackageConfiguration. OMG Issue No: 5962: Yes (the title needs to be changed in the report) OMG Issue No: 5963: No - I couldn't figure out what the changes were supposed to be. OMG Issue No: 5964: No - Make sure instructions say to update the diagrams (for the label to name change) and the diagram in 6.4.1 (for the new class if necessary) In the dependsOn association remove the text ", assigning names to each" . In the referencedArtifact association its definition should be more descriptive, to explain that it represents to pointer to another artifact. Section 6.4.9.1 still has references to the "label" attribute. OMG Issue No: 5983: Yes OMG Issue No: 5984: Yes OMG Issue No: 5985: No - This change also needs to incorporate the T2 to T3 transformation in 9.1 OMG Issue No: 5986: Yes OMG Issue No: 5993: Yes OMG Issue No: 6024: Yes OMG Issue No: 6037: Yes OMG Issue No: 6038: Yes OMG Issue No: 6041: Yes OMG Issue No: 6042: No - This may be a hostage for another item which will result in an issue being raised, but section 8.2.4.1 describes capabilities not capacities OMG Issue No: 6044: Yes OMG Issue No: 6046: Yes OMG Issue No: 6048: Yes OMG Issue No: 6051: Yes OMG Issue No: 6052: Yes Kevin > > Andreas Hoffmann > > unhofer.de> cc: > Subject: Deployment FTF voting (1st poll), closing 20th October 2003 20:00 GMT > 10/02/2003 10:07 AM > > > > Hi FTF members, > > this is the first voting for the OMG Deployment FTF. For details on the > issue resolutions please refer to the attached document listing all the > issue resolutions of this voting. Compared to Tuesday's draft version I > have added issue 5962 and moved issues 5993, 6044 and 6052 from "Resolved" > to "Duplicate or merged". Anyway, this classification has no impact on the > voting. > > In order to give all FTF members enough time to study the issue resolutions > and their impacts on the specification the voting deadline is Monday 20th > October, 2003, 20:00 GMT. > > ------------------- snip -------------------- > > ** Deployment FTF Voting Poll 1 ** > ** Voting Deadline October 20, 2003, 20:00 GMT ** > > Company: > > Voter: > > Regards > Andreas > > ==================================================================== > Andreas Hoffmann > Fraunhofer FOKUS - Research Institute for Open Communication Systems > Kaiserin-Augusta-Allee 31 > D - 10589 Berlin > > Phone: +49 30 3463-7392 > Fax: +49 30 3463-8392 > Email: andreas.hoffmann@fokus.fraunhofer.de > ==================================================================== > > (See attached file: omg-deployment-ftf-01_10_03.zip) > > ------------------------------------------------------------------------ > Name: omg-deployment-ftf-01_10_03.zip > omg-deployment-ftf-01_10_03.zip Type: application/zip > Encoding: base64 > Download Status: Not downloaded with message Date: Fri, 17 Oct 2003 17:38:29 -0400 From: James Kulp Organization: Mercury Computer Systems, Inc. User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en,pdf To: dahaverk@rockwellcollins.com CC: deployment-ftf@omg.org Subject: Re: Deployment FTF voting (1st poll), closing 20th October 2003 20:00 GMT Dave, I'll just try to provide a bit more explanation for the issues you didn't find acceptable (since Frank is out today). It is unfortunate that some of these issues were not raised during our discussions - or in email dialog. dahaverk@rockwellcollins.com wrote: Please vote with Yes/No/Abstain for each issue resolution, as detailed in the attachment. Note: A short reason for No votes is mandatory. OMG Issue No: 5953: Yes. OMG Issue No: 5954: Yes. OMG Issue No: 5955: No. - Not sufficient rationale/justification for adding this additonal complexity. No example of problem being solved by adding this new class. This was an issue where the class in question was being used in two places, but it turned out that it was not appropriate to re-use - thus rather than using the ComponentPackageReference class in two places, the case of using it as an implementation dependency was incorrect. It previously indicated such dependencies as pointers to implementations (ComponentPackageReference). The change specifies the dependency in a way that is simpler and lighter: that an application of a certain type had to be running, but not necessarily one that the implementer knew a package reference (implementation pointer) for. So the "complexity" of the extra class that has a single string attribute allows the dependency to be simpler, and more flexible - indicate an interface, not an implementation OMG Issue No: 5956: Yes. OMG Issue No: 5957: Yes. OMG Issue No: 5958: Yes. OMG Issue No: 5959: Yes. OMG Issue No: 5960: Yes. OMG Issue No: 5961: Yes. OMG Issue No: 5962: Yes. OMG Issue No: 5963: No. - UUID's, Labels, Attributes should not be optional. The Attributes should clearly be required if needed. This solution causes confusion and presents difficulties for tools and applications to anticipate appropriate actions. This issue as written simply says that attributes that are already optional in the spec should be expressed in a more consistent and better way. It is not making any attributes optional. If you think certain attributes in the spec should or should not be optional, that is a separate issue. UUIDs and labels were just used as examples. OMG Issue No: 5964: Yes. OMG Issue No: 5983: Yes. OMG Issue No: 5984: Yes. OMG Issue No: 5985: Yes. OMG Issue No: 5986: Yes. OMG Issue No: 5993: No. Voting No on Issue 6024 requires a different solution for this issue. Indeed this could have been specified in a standalone way since the issue 6024 change simply solved this by replacing a MIME reference to base64 encoding with the xsd:base64Binary instead -- which is already built in to XML schemas - obviating the MIME reference. OMG Issue No: 6024: No. Solution allows/causes XML parsing errors. Need to re-think this solution so that validating parsers work with the XML. Per your email with Frank, we'll have to figure out whether this is a problem with the schema or a problem with your tools. No specific error in the schema was identified. I'll try to look at this further tomorrow (Saturday). The tool you use is evidently available for a free trial! Jim OMG Issue No: 6037: Yes. OMG Issue No: 6038: Yes. OMG Issue No: 6041: Yes. OMG Issue No: 6042: Yes. OMG Issue No: 6044: Yes. OMG Issue No: 6046: Yes. OMG Issue No: 6048: Yes. OMG Issue No: 6051: Yes. OMG Issue No: 6052: Yes. ------------------- snip -------------------- Andreas Hoffmann unhofer.de> cc: Subject: Deployment FTF voting (1st poll), closing 20th October 2003 20:00 GMT 10/02/2003 10:07 AM Hi FTF members, this is the first voting for the OMG Deployment FTF. For details on the issue resolutions please refer to the attached document listing all the issue resolutions of this voting. Compared to Tuesday's draft version I have added issue 5962 and moved issues 5993, 6044 and 6052 from "Resolved" to "Duplicate or merged". Anyway, this classification has no impact on the voting. In order to give all FTF members enough time to study the issue resolutions and their impacts on the specification the voting deadline is Monday 20th October, 2003, 20:00 GMT. ------------------- snip -------------------- ** Deployment FTF Voting Poll 1 ** ** Voting Deadline October 20, 2003, 20:00 GMT ** Company: Voter: Regards Andreas ==================================================================== Andreas Hoffmann Fraunhofer FOKUS - Research Institute for Open Communication Systems Kaiserin-Augusta-Allee 31 D - 10589 Berlin Phone: +49 30 3463-7392 Fax: +49 30 3463-8392 Email: andreas.hoffmann@fokus.fraunhofer.de ==================================================================== (See attached file: omg-deployment-ftf-01_10_03.zip) Date: Sat, 18 Oct 2003 09:04:12 -0400 From: James Kulp Organization: Mercury Computer Systems, Inc. User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en,pdf To: Kevin Richardson CC: deployment-ftf@omg.org Subject: Re: Deployment FTF voting (1st poll), closing 20th October 2003 20:00 GMT Kevin, Similar to the email to Dave, since Frank isn't around, I'll try to clarify some of the issues that you didn't want to accept. In general, to make progress, when comments come up at the ballot that were not raised earlier during the email and telecon discussions, it might be more efficient to raise them as new issues - especially in the case where they are making minor improvements to the larger proposed resolutions. Your call of course. Kevin Richardson wrote: One note, please consider indicate the exact subsections where the modifications are to take place (this makes it much easier for me to find the text in the document) OMG Issue No: 5953: Yes OMG Issue No: 5954: Yes OMG Issue No: 5955: No - I'd suggest that the semantics of ComponentPackageReference be made more generic and that the particulars of each association to it be restructured to specify the semantics of how a componentpackagerefernce should be used in that case The core difference was between a reference to an implementation vs. a reference to an interface, which were considered to be distinct enough to warrant different classes. OMG Issue No: 5956: Yes OMG Issue No: 5957: No - in InstanceDeploymentDescrition, PlanConnectionDescription, PlanPropertyMapping, PackageError there are still references to the label attribute. The resolution should also contain explicit instructions to update the figures. (if these are incorporated - Yes) OMG Issue No: 5958: Yes OMG Issue No: 5959: No - I've got a couple of discussion items before I say yes, 1) In the GenericTransformationRules it states the "an XML schema for persistent storage of metadata" - is it the case that the metadata has to be persistently maintained? The persistence is certainly not normative. Perhaps such a clarification should be a separate issue? The core issue of using the standard XMI->XML Schema mapping was mandated by the Architecture Board. 2) The paragraph beginning with "Composition associations in the model..." confuses me to no end, am I just missing something? Me too:-) Perhaps a separate issue to clarify these few sentences? OMG Issue No: 5960: Yes OMG Issue No: 5961: No - The semantics of CreatePackage need to better explain what distinguishes this operation from InstallPackage - you can probably use some of the text from the summary. It should also explicitly state that it creates the new PackageConfiguration. This new operation description was carefully written to mirror the wording for the installPackage operation, which, now that I look at it, could benefit from your comments in the same way. Perhaps a new issue that applied your comments to both? OMG Issue No: 5962: Yes (the title needs to be changed in the report) OMG Issue No: 5963: No - I couldn't figure out what the changes were supposed to be. The changes were all to change "String" to "String[0..1]" for the attributes already specified in the text as "optional". OMG Issue No: 5964: No - Make sure instructions say to update the diagrams (for the label to name change) and the diagram in 6.4.1 (for the new class if necessary) In the dependsOn association remove the text ", assigning names to each" . In the referencedArtifact association its definition should be more descriptive, to explain that it represents to pointer to another artifact. Section 6.4.9.1 still has references to the "label" attribute. These good refinements should be submitted as a new issue if this passes... OMG Issue No: 5983: Yes OMG Issue No: 5984: Yes OMG Issue No: 5985: No - This change also needs to incorporate the T2 to T3 transformation in 9.1 OMG Issue No: 5986: Yes OMG Issue No: 5993: Yes OMG Issue No: 6024: Yes OMG Issue No: 6037: Yes OMG Issue No: 6038: Yes OMG Issue No: 6041: Yes OMG Issue No: 6042: No - This may be a hostage for another item which will result in an issue being raised, but section 8.2.4.1 describes capabilities not capacities 6042 was a spelling error. Do you mean a different issue? OMG Issue No: 6044: Yes OMG Issue No: 6046: Yes OMG Issue No: 6048: Yes OMG Issue No: 6051: Yes OMG Issue No: 6052: Yes Kevin Andreas Hoffmann unhofer.de> cc: Subject: Deployment FTF voting (1st poll), closing 20th October 2003 20:00 GMT 10/02/2003 10:07 AM Hi FTF members, this is the first voting for the OMG Deployment FTF. For details on the issue resolutions please refer to the attached document listing all the issue resolutions of this voting. Compared to Tuesday's draft version I have added issue 5962 and moved issues 5993, 6044 and 6052 from "Resolved" to "Duplicate or merged". Anyway, this classification has no impact on the voting. In order to give all FTF members enough time to study the issue resolutions and their impacts on the specification the voting deadline is Monday 20th October, 2003, 20:00 GMT. ------------------- snip -------------------- ** Deployment FTF Voting Poll 1 ** ** Voting Deadline October 20, 2003, 20:00 GMT ** Company: Voter: Regards Andreas ==================================================================== Andreas Hoffmann Fraunhofer FOKUS - Research Institute for Open Communication Systems Kaiserin-Augusta-Allee 31 D - 10589 Berlin Phone: +49 30 3463-7392 Fax: +49 30 3463-8392 Email: andreas.hoffmann@fokus.fraunhofer.de ==================================================================== (See attached file: omg-deployment-ftf-01_10_03.zip) ------------------------------------------------------------------------ Name: omg-deployment-ftf-01_10_03.zip omg-deployment-ftf-01_10_03.zip Type: application/zip Encoding: base64 Download Status: Not downloaded with message Subject: Re: Deployment FTF voting (1st poll), closing 20th October 2003 20:00 GMT To: deployment-ftf@omg.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 From: Gerald_L_Bickle@raytheon.com Date: Mon, 20 Oct 2003 09:45:46 -0500 X-MIMETrack: Serialize by Router on NotesServer3/HDC(Release 5.0.12 |February 13, 2003) at 10/20/2003 09:44:34 AM OMG Issue No: 5953: Yes. OMG Issue No: 5954: Yes. OMG Issue No: 5955: No. - Not clear why another class is needed. Changing the meaning of depends on. It seems like there is different dependencies types, loading, execution, uses. This needs further thought with use cases and use case realizations to show justification. OMG Issue No: 5956: Yes. OMG Issue No: 5957: Yes, but diagrams need to be updated too OMG Issue No: 5958: Yes. OMG Issue No: 5959: Yes., chapter misspelled in 1st change OMG Issue No: 5960: Yes. OMG Issue No: 5961: no, what is the relationships between this and the install operation. What is the outcome of a createpackage? OMG Issue No: 5962: Yes. OMG Issue No: 5963: No. - It appears the changes are being made to agree with the corresponding text. I don't think the text is correct. These attributes should not be optional. OMG Issue No: 5964: NO, Which issue change has precedence 5957? No mention of updating corresponding diagrams. Without updated diagrams with text changes it is unclear why all these changes are necessary and how all these changes fit together. OMG Issue No: 5983: Yes. OMG Issue No: 5984: Yes. OMG Issue No: 5985: Yes. OMG Issue No: 5986: Yes. OMG Issue No: 5993: Yes if this valid for XML and transformation rules. solution for this issue. OMG Issue No: 6024: Yes, provided the XML is valid syntax. OMG Issue No: 6037: Yes. OMG Issue No: 6038: Yes. OMG Issue No: 6041: Yes. OMG Issue No: 6042: Yes OMG Issue No: 6044: Yes. OMG Issue No: 6046: Yes. OMG Issue No: 6048: Yes. OMG Issue No: 6051: Yes. OMG Issue No: 6052: Yes. Jerry Bickle Senior Principal Software Engineer Network Centric Systems 1010 Production Rd Fort Wayne, IN 46808-4711 260-429-6280 260-429-5060 Fax m: "Francis Bordeleau" To: "Andreas Hoffmann" , "Deployment FTF" Subject: RE: Deployment FTF voting (1st poll), closing 20th October 2003 20:00 GMT Date: Mon, 20 Oct 2003 20:52:25 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal Hi All, No, I am not dead! I apologize for having been out of the loop since the Paris meeting, but I have completely swamped with different things (different project funding propositions, software radio submission, graduate student projects, ...) and it seems that I had a meeting every morning when there was a teleconf, and did not have any meetings the other Wednesdays. Anyway, here is my vote. I should be back on the active mode from now on. I am sorry for sending this email 6 hours after the official end of the poll, but I am at the UML conference this week and there are no internet connections in the location where we are today for the workshops (and I was expecting to be able to send it when coming in this morning). So I had to wait until I come back to the hotel to send the email. I left a voice message to Frank at Mercury to let him know. Hopefully, my vote can still be considered. Thanks, Francis OMG Issue No: 5953: YES OMG Issue No: 5954: YES OMG Issue No: 5955: ABSTAIN. I do not see what problem the new solution solves. The issue is not very well described. So in summary, I abstain instead of voting "NO" because I am guilty of not having participated to the discussion. OMG Issue No: 5956: YES OMG Issue No: 5957: YES OMG Issue No: 5958: YES OMG Issue No: 5959: YES OMG Issue No: 5960: YES. However, we should explicitly mention that the current specification does not address the implementation selection issue. OMG Issue No: 5961: NO. I think that the solution might be right, but the argument is too weak. Not convincing at all. E.g. " It might be useful to have ...", This method would do less than" (please explain). OMG Issue No: 5962: YES OMG Issue No: 5963: YES OMG Issue No: 5964: NO. I do not see how changing "label" for "name" solves the problem. OMG Issue No: 5983: YES OMG Issue No: 5984: YES OMG Issue No: 5985: YES OMG Issue No: 5986: YES OMG Issue No: 5993: YES OMG Issue No: 6024: ABSTAIN. I am not sure of the implication of this change. Any impact? OMG Issue No: 6037: YES OMG Issue No: 6038: YES OMG Issue No: 6041: YES OMG Issue No: 6042: YES OMG Issue No: 6044: YES OMG Issue No: 6046: YES OMG Issue No: 6048: YES OMG Issue No: 6051: YES OMG Issue No: 6052: YES ------------------- snip -------------------- Regards Andreas ==================================================================== Andreas Hoffmann Fraunhofer FOKUS - Research Institute for Open Communication Systems Kaiserin-Augusta-Allee 31 D - 10589 Berlin Phone: +49 30 3463-7392 Fax: +49 30 3463-8392 Email: andreas.hoffmann@fokus.fraunhofer.de ====================================================================