Issue 6027: Submission allows multiple objects with identical names (unique identifiers (deployment-ftf) Source: Rockwell Collins (Mr. David Fitkin, nobody) Nature: Uncategorized Issue Severity: Summary: Subject: Submission allows multiple objects with identical names (unique identifiers, UUID, URI). Problem: This creates an enormous potential risk for object identification errors, by allowing duplicate identities to exist. Risks include problems reclaiming resources, naming service references, etc. Some examples of this area of concern are provided below, there might be other instances that have not been identified in this list. MOF 2.0 document states 8.3. Classifier requirements for instantiation Names must be unique within Class, Package, and Operation Examples: 6.4.3.4 Constraints If the UUID attribute is not the empty string, then it must contain a unique identifier for the package; packages with the same non-empty UUID must be identical. 6.4.4.4 Constraints If the UUID attribute is not the empty string, then it must contain a unique identifier for the implementation; implementations with the same non-empty UUID must be identical. 6.4.15.4 Constraints If the UUID field is non-empty, then it must contain a unique identifier for the artifact; artifacts with the same non-empty UUID must be identical. 6.4.17.4 Constraints If the UUID field is non-empty, then it must contain a unique identifier for the interface; interfaces with the same non-empty UUID must be identical. Proposed Resolution: Correct requirements to disallow any use of duplicate (identical) identifiers in all defined name spaces. Resolution: Revised Text: Actions taken: July 29, 2003: received issue Discussion: End of Annotations:===== m: To: issues@omg.org Subject: Issue for the Deployment Finalization Task Force X-Mailer: Lotus Notes Release 5.0.10 March 22, 2002 Date: Tue, 29 Jul 2003 09:27:26 -0500 X-MIMETrack: Serialize by Router on CollinsCRSMTP02/CedarRapids/RockwellCollins(Release 5.0.10 |March 22, 2002) at 07/29/2003 09:48:53 AM, Serialize complete at 07/29/2003 09:48:53 AM Issue for the Deployment Finalization Task Force Subject: Submission allows multiple objects with identical names (unique identifiers, UUID, URI). Problem: This creates an enormous potential risk for object identification errors, by allowing duplicate identities to exist. Risks include problems reclaiming resources, naming service references, etc. Some examples of this area of concern are provided below, there might be other instances that have not been identified in this list. MOF 2.0 document states 8.3. Classifier requirements for instantiation Names must be unique within Class, Package, and Operation Examples: 6.4.3.4 Constraints If the UUID attribute is not the empty string, then it must contain a unique identifier for the package; packages with the same non-empty UUID must be identical. 6.4.4.4 Constraints If the UUID attribute is not the empty string, then it must contain a unique identifier for the implementation; implementations with the same non-empty UUID must be identical. 6.4.15.4 Constraints If the UUID field is non-empty, then it must contain a unique identifier for the artifact; artifacts with the same non-empty UUID must be identical. 6.4.17.4 Constraints If the UUID field is non-empty, then it must contain a unique identifier for the interface; interfaces with the same non-empty UUID must be identical. Proposed Resolution: Correct requirements to disallow any use of duplicate (identical) identifiers in all defined name spaces. David Fitkin Rockwell Collins  Subject: Re: issue 6027 Date: Wed, 30 Jul 2003 09:11:31 -0400 Thread-Topic: issues 6024 - 6027 -- Deployment FTF issues Thread-Index: AcNV9uP+oPIIysHYEdeMjQCgyTbmFwAoydfQ From: "Pilhofer, Frank" To: X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id h6UD8QkM019976 > > Submission allows multiple objects with identical names (unique > identifiers, UUID, URI). > > Examples: > If the UUID attribute is not the empty string, then it must contain > a unique identifier for the package; packages with the same > non-empty UUID must be identical. > The UUID is intended to be globally unique - packages with the same UUID can be expected to be identical. The exception - the empty string - was included mostly for testing and rapid prototyping. I consider the empty string to be "no identity" rather than a potentially duplicate identity. It is just impractical to generate true unique UUIDs every time you run a test - but that's what you would have to do: if you change anything, the UUID has to change, too. So rather than inviting people to cheat in practice - which an inter- face change without corresponding UUID change would be, even in a test environment - we instead allow people to officially bypass this constraint by allowing packages with no identity to exist. That at least is the rationale, let's see what the other opinions are. Maybe this will become more clear in combination with issue 5963 (use of optional attributes for optional values); it would allow UUID fields to be absent (rather than empty) in an XML document. Frank