Er, no. *VRML*browsers*, as valid HTTP browsers, have to implement all
these, but the *VRML*specification* doesn't have to say anything about
them. It just refers to a "URL", and the URL specification takes it from
there.
> and will most likely use features
> garnered from HTTP-NG, RTP, MBONE, JAVA, and other technologies.
Build a general binding mechanism between VRML and these *types* of
technologies, and when Java-NG comes around VRML won't have to be changed
at all.
> As far as I know, VRML has very little more progress to make on the
> "graphics" front. Sound is not a graphics issue, nor is caching nor, even,
> is interactivity. The first and last of these are clearly more
> network-based issues/implementations than graphics technologies.
Er, no. They are all *browser* issues, or World Wide Web issues, not
VRML issues. If you have a suggestion for improving caching in HTTP
systems, for example, the right place to deal with it is on the http or
www-talk mailing lists. If VRML contains enough semantic information to
describe a scene, then the browser can make intelligent decisions as to
how to "render" sound in it.
Brian