Using Extension-List in MANIFEST.MF jar files allows to specify dependencies between libraries or webapps. When a jar depends on an Extension without specifying an Implementation-Vendor-Id AND the corresponding extension does not specify an Implementation-Vendor-Id, tomcat fails loading the corresponding context claiming for a missing dependency. I thing that in this case (no Implementation-Vendor-Id in either files) the Implementation-Vendor-Id's must be considered OK and that it must not be enought to consider the dependency broken.
Do you have a reference for a relevant speicifcation that requires the behaviour you describe? I can't find one. I am leaning towards your interpretation but I would like to see a proper definition of the required behaviour.
The servlet spec v.2.3 p. 63 just makes a reference to the manifest spec specifying that the web container must reject the app and display an informative message if it can not satisfy a dependency. On the other hand, the manifest spec (http://java.sun.com/j2se/1.3/docs/guide/extensions/versioning.html) specifies the behavior of the Java plugin. Since the servlet specification makes a direct reference to this manifest specification, I think we can consider that this behavior also applies to web containers. It specifies that : <extension>-Specification-Version <extension>-Implementation-Version <extension>-Implementation-Vendor-Id are all *OPTIONAL* in a manifest that indicate a dependency to <extension>. Moreover, still in manifest specification : "If the applet's manifest doesn't contain one or more of the optional attributes, the plug-in will accept any value of the corresponding attribute in the optional package's manifest." I suppose that "any value" also include no value. Hope it helps.
The attributes are optional for the plugin manifest but the same reference also states: "Note that all of the above manifest attributes should be included in an optional package's manifest." The key word here is "should". If it was "must", the current Tomcat behaviour would be fine. Nothing states explicity what the desired behaviour is if the optional package's manifest does not include one of the attributes. Your interpretation is a sensible one but hinges on the assumption that "any value" is the same as "no value". I want to think about this for a little while before I make any changes. Watch this space...
This and some related issues have been fixed in TC4 and TC5.