[x3d-public] X3D minutes16 July 2020: Inline refresh, https, description; X3DUrlObject

[Don Brutzman]

On 7/17/2020 9:51 AM, Don Brutzman wrote:
> [...]
> 
> 6. Specification readiness review
> 
> [6] Mantis Issues List
>      https://www.web3d.org/member-only/mantis/view_all_bug_page.php
> [...]
> e. Mantis 1273 Inline https support
> f. Mantis 1262 Inline refresh
> [...]
> 
> Accepted [...]

Several refinements on these mantis issues, request external review please.  Hopefully OK.

----

a. https support: rather than Inline, this actually belongs in

[1] Mantis 1273: https level support requirements should match http level support
     https://www.web3d.org/member-only/mantis/view.php?id=1273

====================================
9.2.1 Networking component, URLs

A URL (Uniform Resource Locator), described in 2.[RFC1738], is a form of Universal Resource Identifier (URI) that specifies a file located on a particular server and accessed through a specified protocol (e.g., http). In this part of ISO/IEC 19775, the upper-case term URL refers to a Uniform Resource Locator, while the italicized lower-case version url refers to a field which may contain URLs or in-line encoded data.

Higher levels of this component extend the URL support of a browser to additional forms of URI, such as supporting URNs (Uniform Resource Name), which are another form of URI. A URN allows an abstract resolution mechanism to be invoked to locate a resource (see 2.[RFC2141]). This allows a resource to be located on the local machine or a platform dependent resource to be located using the URN along with platform-specific identifiers.

For levels that support URNs, the url field shall also support the Web3D Consortium URN Namespace (see 2.[RFC3541]) and also support the Universal Media Library that may be accessed using that namespace. A URN allows an abstract resolution mechanism to be invoked to locate a resource (see 2.[RFC2141]). This allows a resource to located on the local machine or a platform dependent resource to be located using the URN along with platform specific identifiers. A component extension can extend the URL support of a browser by supporting other URN naming schemes. More information on the url field may be found in 9.3.2 X3DUrlObject.

More general information on URLs is described in 2.[RFC1738].
====================================

Interesting this clause says only "e.g http" (example given).  Suggested change: "(e.g http or https)" and then, in clause 9.5 Support levels,

Current entries:

================================================
Level 	Prerequisites 	Nodes/Features 	Support

2 	Core 1          Protocols 	file: and http: protocols are required.
         Grouping 1 	  	
[...]

4 	Core 1 	       Level 3 supported nodes, Support as specified for Level 3.
         Grouping 1     Protocols 	        https: protocol is required.
   	  	       Communication security 	HTTP and HTTPS username/password is required.
================================================

So editorial resolution of this accepted comment will simply be to merge level 4 requirements with level 2, then remove level 4.

----

b. Consolidation of refresh:

[2] Mantis 1262 : new field /refresh/ for Inline, ImageTexture etc.
     https://www.web3d.org/member-only/mantis/view.php?id=1262

The following nodes are all affected by suggested changes:

[2] X3DJSAIL Package org.web3d.x3d.sai.Networking Interface X3DUrlObject
     https://www.web3d.org/specifications/java/javadoc/org/web3d/x3d/sai/Networking/X3DUrlObject.html

>  All Known Subinterfaces:
>     Anchor, AudioClip, DISEntityTypeMapping, GeoMetadata, ImageCubeMapTexture,
>     ImageTexture, ImageTexture3D, Inline, MovieTexture, PackagedShader, Script,
>     ShaderPart, ShaderProgram, X3DScriptNode

Next, since each url field can refer to an external asset, it is appropriate to add a 'description' field.  We have node similarly in a number of other nodes (including Anchor already).

Next, rather than change each and every relevant node individually, am thinking the change is better applied to X3DUrlObject interface:

====================================
9.3.2 X3DUrlObject

X3DUrlObject {
   SFString [in,out] description    ""
   MFString [in,out] url         [] [URI]
   SFTime   [in,out] refresh     0  [0,+infinity)
}
====================================

Suggested prose: "The /refresh/ field defines the interval in seconds that are necessary before an automatic reload of the current /url/ asset is performed. If the preceding file loading fails or the /load/ field is FALSE, no refresh is performed. If performed, a refresh attempts to reload the currently loaded entry of the url list. If a refresh fails to reload the currently loaded url entry, the browser retries the other entries in the /url/ list."

We should add:

"NOTE. Automatically reloading content can have security considerations and needs to be considered carefully."

Variations among nodes implementing X3DUrlObject can be handled cleanly in specification prose as follows:

9.4.1 Anchor

	"The /refresh/ field has no effect."

29.3.1 X3DScriptNode

	"If the /refresh/ field results in a new script getting loaded or the prior script getting reloaded,
	 then all fields are re-initialized to their initially defined values, and
	 the initialize() method is invoked, if provided, as defined in 29.2.3 initialize() and shutdown()."

Does this look OK?  Anything else to consider?

all the best, Don
-- 
Don Brutzman  Naval Postgraduate School, Code USW/Br       brutzman at nps.edu
Watkins 270,  MOVES Institute, Monterey CA 93943-5000 USA   +1.831.656.2149
X3D graphics, virtual worlds, navy robotics http://faculty.nps.edu/brutzman