[x3d-public] X3D minutes 4 DEC 2020: resolving X3D4 endgame issues: autoRefresh/autoRefreshTimeLimit and event utility changes complete

[Don Brutzman]

Selected summaries of applied changes follows.

On 12/4/2020 10:41 AM, Don Brutzman wrote:
> [...]
> 
> 1. X3D4 topics
> 
> [1.0] X3D4
>         https://www.web3D.org/x3d4
> 
> Changes to X3D4 specification on members-only github are also being refreshed daily at
> 
> [1.1] X3D4 Working Draft 3
>        https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-WD3/
> 
> Corresponding pristine text in preparation for Web3D Consortium member ballot is currently being autogenerated along with a log of both corrections and remaining issues.
> [...]
> 
> d. Putting default duration bounds on url refresh activity
> 
> Clearly we don't want a lot of unclosed 3D scenes and window frames becoming zombie network loads (or even Denial Of Service DOS threats).
> 
> [5] [x3d-public] X3D4 security-related field addition: X3DUrlObject refreshTimeLimit
>       http://web3d.org/pipermail/x3d-public_web3d.org/2020-November/014182.html
> 
> with John Carlson's follow-on reply exploring rationale and examples further.
> 
> Recommendation: include this field (X3DUrlObject refreshTimeLimit) as a prudent security precaution.
> 
> ========================
> 9.3.2 X3DUrlObject
> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-WD3/Part01/components/networking.html#X3DUrlObject
> 
> X3DUrlObject {
>     SFString [in,out] description ""
>     SFBool   [in,out] load        TRUE
>     SFTime   [in,out] refresh     0.0 [0,∞)
>     MFString [in,out] url         []  [URI]
> }
> [...]
> =====================
> 
> Proposed field for maximum refresh duration.  Note this is not the same as browser working its way through url list, and finding or timing out on any individual url, which is owned by the software implementation and the associated network protocol.
> 
>     SFTime   [in,out] refreshTimeLimit  3600.0  [0,infinity]
> 
> "The refreshTimeLimit field defines the maximum duration in seconds that /refresh/ activity is allowed to occur.  This field is intended to reduce potential risks associated with indefinite repetition of automatic link retrieval. Setting the /load/ field to TRUE resets the refreshTimeLimit clock. If refreshTimeLimit is exceeded then load is set to FALSE."
> 
> Alternate names might be autoRefreshTimeLimit, together with renaming /refresh/ as /autoRefresh/.
> 
> X3DUrlObject {
>     SFString [in,out] description           ""
>     SFBool   [in,out] load                  TRUE
>     SFTime   [in,out] autoRefresh           0.0     [0,∞)
>     SFTime   [in,out] autoRefreshTimeLimit  3600.0  [0,infinity]
>     MFString [in,out] url                   []      [URI]
> }
> [...]
> 
> Absent further comment, we expect to proceed with this clarifying naming refinement.

added note to Mantis regarding this change.

* Mantis 1262: new fields refresh and description for X3DUrlObject (Inline, ImageTexture etc.)
   https://www.web3d.org/member-only/mantis/view.php?id=1262

Change applied to draft specification, affects 15 nodes as well as X3DUrlObject. Committed and pushed.

* X3D4 Networking component, 9.3.2 X3DUrlObject
   https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-WD3/Part01/components/networking.html#X3DUrlObject

Committed corresponding changes to X3D XML Schema and X3D XML DOCTYPE. Building X3DUOM, Java X3DJSAIL and Python X3DPSAIL, also X3D Ontology.

Deploying all validation and software build products tonight.

> [...]
> 
> g. Event Utility node clarifications
> 
> Thanks Andreas for remembering this long-overlooked issue.
> 
> [8.0] [x3d-public] X3D4 draft nearing readiness for ballot; Mantis 519 Event utilities, ignoring set_boolean false events
>         https://web3d.org/pipermail/x3d-public_web3d.org/2020-November/014185.html
> 
> This applies to IntegerTrigger and TimeTrigger nodes, ignoring set_boolean FALSE improves logical understanding and simplifies event animation chains.
> 
> Absent objections (none heard) will apply this straightforward change.  No problems with prior compatibility identified as a result of this logical refinement.
> 
> Review led Dick and I to also look at related issue
> 
> [8.1] Mantis 1183, 30.4.6 IntegerTrigger - Ambiguous response when integerKey field is reset
>        https://www.web3d.org/member-only/mantis/view.php?id=1183
> 
>> Suggested clarification to ensure consistent implementations and expectations: append
>> "Resetting the integerKey field generates a corresponding integerKey field output event."
> 
> also related:
> 
> [8.2] Mantis 1182: 30.4.3 BooleanToggle - Ambiguous response when toggle field is reset
>         https://www.web3d.org/member-only/mantis/view.php?id=1182
> 
>> "Resetting the toggle field generates a corresponding toggle field output event."
> 
> Absent objections, we plan to apply all of these related simple/sensible clarifications to X3D4 specification prose.

Changes applied.  Ready to close Mantis 519 520 1182 1183.

> [...]

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