[x3d-public] Fw: Tiny VPN for Use by Web3D Community (max. 10 connections at a time)
John Carlson
yottzumm at gmail.com
Mon Jan 25 16:27:40 PST 2021
netstat -g looks useful for determining multicast addresses.
John
On 1/25/21 6:11 PM, John Carlson wrote:
>
> I figured out how to translate into English!
>
>
> John
>
> On 1/25/21 6:08 PM, John Carlson wrote:
>>
>> Ah, no VPN required!
>>
>>
>> John
>>
>>
>> On 1/25/21 5:33 PM, John Carlson wrote:
>>
>>> Okay, so I have to schedule on a calender when to use VPN, but first
>>> I have to get on VPN
>>>
>>> I got to the calendar. Is there some way to translate to English?
>>>
>>> This is the point where you steal my files? It always seems to
>>> happen with VPN.
>>>
>>> On 1/25/21 5:08 PM, Christoph Valentin wrote:
>>>> Hi John,
>>>> You can access the VPN's calendar directly at the experimental
>>>> owncloud web interface at my vServer:
>>>> (owncloud is a framework mainly for file sharing, but also has
>>>> calendar and contacts via WebDav)
>>>> URL https://lc-soc-lc.at/owncloud <http://lc-soc-lc.at/owncloud>
>>>> user name vpncal
>>>> password X3D4
>>>> All the best
>>>> Christoph
>>>> *Gesendet:* Sonntag, 24. Januar 2021 um 15:35 Uhr
>>>> *Von:* "Christoph Valentin" <christoph.valentin at gmx.at>
>>>> *An:* "John Carlson" <yottzumm at gmail.com>
>>>> *Cc:* "X3D Graphics public mailing list" <x3d-public at web3d.org>
>>>> *Betreff:* [x3d-public] Fw: Tiny VPN for Use by Web3D Community
>>>> (max. 10 connections at a time)
>>>> John,
>>>> Please *expect some maintenance work (short interruptions) next
>>>> week Saturday (30th January).*
>>>> I have now *defined an online calendar for the VPN*, to avoid
>>>> flooding the mailing list.
>>>> The calendar can be *easily integrated with the calendar on your
>>>> Android phone* (see the green entry below!!!).
>>>> Probably it is possible to integrate it with any smartphone (it
>>>> uses the WebDav standard), but I haven't tried.
>>>> Installation instructions:
>>>> 1) Install DAVx5 on your Android smartphone (available at F-Droid)
>>>> 2) Create new DAVx5 account "vpncal at lc-soc-lc.at"
>>>> - URL:
>>>> https://lc-soc-lc.at/owncloud/remote.php/dav/calendars/vpncal/personal/
>>>> <https://lc-soc-lc.at/owncloud/remote.php/dav/calendars/vpncal/personal/>
>>>> - user: vpncal
>>>> - pw: X3D4
>>>> 3) Enable and trigger the synchronization of WebCal
>>>> 4) Go to "Calendar" App: make sure the "personal" calendar is
>>>> activated for display
>>>> The installation instructions will be available at
>>>> https://lc-soc-lc.at/experimental
>>>> <https://lc-soc-lc.at/experimental> soon.
>>>> If you have set the synchronization correctly, then it should be
>>>> possible for you to make calendar entries, too (e.g. test sessions,
>>>> where you need more than 2 connections, or some specific multicast
>>>> address).
>>>> KR
>>>> Christoph
>>>> *Gesendet:* Samstag, 23. Januar 2021 um 14:11 Uhr
>>>> *Von:* "Christoph Valentin" <christoph.valentin at gmx.at>
>>>> *An:* "X3D Graphics public mailing list" <x3d-public at web3d.org>
>>>> *Betreff:* [x3d-public] Tiny VPN for Use by Web3D Community (max.
>>>> 10 connections at a time)
>>>> Hi John, Gina Lauren, Jordi, and all interested in multiuser
>>>> Being very curious to get to know, whether the "server-less mode"
>>>> could really work, I was thinking about what could I contribute?
>>>> I have got this tiny vServer at hoststar.at (hosted at some cloud
>>>> in Germany), where I could implement a VPN for "server-less
>>>> experiments".
>>>> Voilá
>>>> So, if you have a Windows 10 client, then what you can do:
>>>> 1) Install OpenVPN Connect software (community edition) -
>>>> https://openvpn.net/community-downloads/
>>>> <https://openvpn.net/community-downloads/>
>>>>
>>>> 2) Unzip the config.zip from attachment into C:\Program
>>>> Files\OpenVPN\config
>>>> 3) Start OpenVPN Client
>>>> 4) Connect
>>>> 5) Now your client is a multihomed host with an additional network
>>>> interface at 172.27.224.0/19
>>>> 6) The network 172.27.224.0/19 is an island. Only people, who
>>>> receive this e-mail, can connect.
>>>> What is missing:
>>>> a) a proof that multicast addresses work on the VPN
>>>> b) an online calendar to coordinate the multicast sessions at the
>>>> VPN-> I will provide this on request.
>>>> KR,
>>>> Christoph
>>>>
>>>>
>>>>
>>>> Gesendet: Samstag, 23. Januar 2021 um 01:34 Uhr
>>>> Von: "Christoph Valentin" <christoph.valentin at gmx.at>
>>>> An: "John Carlson" <yottzumm at gmail.com>
>>>> Cc: "X3D Graphics public mailing list" <x3d-public at web3d.org>
>>>> Betreff: Re: [x3d-public] X3D and VRML for multiuser worlds
>>>> Hi John,
>>>>
>>>> Currently having two issues:
>>>>
>>>> 1) can test the VPN only with two Windows clients -> you have to
>>>> create your own experience with the Linux client
>>>> 2) still have to make the VPN permanent -> now the VPN has to be
>>>> restarted manually after server restart.
>>>>
>>>> Pls. expect final answer by Saturday evening, CET.
>>>>
>>>> My plan:
>>>>
>>>> I will publish (at a hidden place):
>>>>
>>>> a) example configuration from Windows OpenVPN Connect client
>>>> b) ca-yeti.crt self-signed root certificate, which you have to trust
>>>> c) x3d-public.key private key for the Web3D community (not really
>>>> private)
>>>> d) x3d-public.crt certificate for the Web3D community (signed by
>>>> yeti -> my server will let you in)
>>>> e) ta.key additional symmetric key (must be identical on client and
>>>> server)
>>>>
>>>> Physical restriction: max. 10 connections at the same time, dynamic
>>>> IP addresses from a private IPv4 range (172.27.224.0/19).
>>>>
>>>> The VPN will be an island - the server will not route that subnet,
>>>> unless from one client to the others (hopefully including multicast
>>>> packets - not yet tested).
>>>>
>>>> KR
>>>> Christoph
>>>>
>>>>
>>>>
>>>> Gesendet: Freitag, 22. Januar 2021 um 07:38 Uhr
>>>> Von: "John Carlson" <yottzumm at gmail.com>
>>>> An: "Christoph Valentin" <christoph.valentin at gmx.at>
>>>> Cc: "X3D Graphics public mailing list" <x3d-public at web3d.org>
>>>> Betreff: Re: [x3d-public] X3D and VRML for multiuser worlds
>>>> I am now prepared to have a "client" of your UDP DIS server at
>>>> hoststar.at. I need things like address and port, per X3D PDU nodes.
>>>>
>>>> If there is ssh information for reaching your server network, let
>>>> me know. This is my preferred method. I do not believe I need
>>>> special permission except for perhaps a new user account.
>>>>
>>>> I've never really used a VPN, and will probably need instructions.
>>>> My experience with VPN varies "not very useful" and "OMG, my
>>>> friends are going to steal my files."
>>>>
>>>> John
>>>>
>>>> On 1/10/21 11:28 PM, Christoph Valentin wrote:
>>>> If everything works fine (and if I've understood correctly), then
>>>> you can do tests with multicast IP transport, although you are
>>>> geographically separated.
>>>>
>>>> That's what I would like to try basically
>>>>
>>>> --
>>>> Diese Nachricht wurde von meinem Android Mobiltelefon mit GMX Mail
>>>> gesendet.
>>>> Am 11.01.21, 05:11 schrieb John Carlson
>>>> <yottzumm at gmail.com>[mailto:yottzumm at gmail.com]:
>>>> My friends have asked me to set up a VPN on my machine in the
>>>> past. I don't really see the value of a VPN.
>>>>
>>>> On Sun, Jan 10, 2021 at 7:03 PM Christoph Valentin
>>>> <christoph.valentin at gmx.at[mailto:christoph.valentin at gmx.at]> wrote:
>>>>
>>>> What I am going to try is to setup a VPN with OpenVPN and my
>>>> vServer at hoststar.at[http://hoststar.at <http://hoststar.at>], so
>>>> we can do a test session with DIS (hopefully).
>>>>
>>>>
>>>>
>>>> Gesendet: Sonntag, 10. Januar 2021 um 23:13 Uhr
>>>> Von: "John Carlson" <yottzumm at gmail.com[mailto:yottzumm at gmail.com]>
>>>> An: "Christoph Valentin"
>>>> <christoph.valentin at gmx.at[mailto:christoph.valentin at gmx.at]>
>>>> Cc: "X3D Graphics public mailing list"
>>>> <x3d-public at web3d.org[mailto:x3d-public at web3d.org]>
>>>> Betreff: Re: [x3d-public] X3D and VRML for multiuser worlds
>>>>
>>>> What I was going to do is try to get DIS from GitHub and DIS from
>>>> X_ITE to talk to each other.
>>>>
>>>> John
>>>>
>>>> On Sun, Jan 10, 2021 at 1:08 PM Christoph Valentin
>>>> <christoph.valentin at gmx.at[mailto:christoph.valentin at gmx.at]> wrote:
>>>> ok
>>>>
>>>> let me repeat your proposal:
>>>>
>>>> >>>>> Of the published work available in that regard, we have BS
>>>> Collaborate, DIS, and the Draft X3D Specification for
>>>> NetworkSensor. I think the first step would be to take these, see
>>>> what they have in common, and go from there for deeper analyses.
>>>>
>>>> I think everybody agrees.
>>>>
>>>> So what would be the very first step (before the first step)?
>>>> Assign responsibilities? Create a Wiki? Ask for official decision?
>>>> Just do it? Who? What? When? Create an official backlog? Use the
>>>> S&P-ARK?
>>>>
>>>> kind regards
>>>> Christoph
>>>>
>>>> --
>>>> Diese Nachricht wurde von meinem Android Mobiltelefon mit GMX Mail
>>>> gesendet.
>>>>
>>>> Am 09.01.21, 07:40 schrieb Christoph Valentin
>>>> <christoph.valentin at gmx.at[mailto:christoph.valentin at gmx.at]>:
>>>>
>>>> Not much,
>>>>
>>>> 1) It's another use case, which has proven it's usefulness during
>>>> SrrTrains v0.01:
>>>> - Customized Client Side Calculations
>>>> ( sent to x3d-public in January 2014:
>>>> https://areasharpa.files.wordpress.com/2018/04/smuos_03_sema_2018_04_27.pdf
>>>> <https://areasharpa.files.wordpress.com/2018/04/smuos_03_sema_2018_04_27.pdf>[https://areasharpa.files.wordpress.com/2018/04/smuos_03_sema_2018_04_27.pdf
>>>> <https://areasharpa.files.wordpress.com/2018/04/smuos_03_sema_2018_04_27.pdf>][https://areasharpa.files.wordpress.com/2018/04/smuos_03_sema_2018_04_27.pdf
>>>> <https://areasharpa.files.wordpress.com/2018/04/smuos_03_sema_2018_04_27.pdf>[https://areasharpa.files.wordpress.com/2018/04/smuos_03_sema_2018_04_27.pdf
>>>> <https://areasharpa.files.wordpress.com/2018/04/smuos_03_sema_2018_04_27.pdf>]]
>>>> )
>>>>
>>>> 2) And an idea (which is not yet settled).
>>>> - idea is to have two levels of identification:
>>>> identify the sensor by "streamName" + "networkSensorId"
>>>> (BS Collaborate: only "streamName"
>>>> Octaga: only "networkSensorId")
>>>>
>>>> 1) the stream = the model = the real life entity
>>>> e.g. "car"
>>>> 2) the sensor nodes themselves
>>>> e.g. "steering", "motor", "doors"
>>>>
>>>>
>>>>
>>>> Gesendet: Samstag, 09. Januar 2021 um 03:59 Uhr
>>>> Von: "GL" <info at 3dnetproductions.com[mailto:info at 3dnetproductions.com]>
>>>> An: "'X3D Graphics public mailing list'"
>>>> <x3d-public at web3d.org[mailto:x3d-public at web3d.org]>
>>>> Betreff: Re: [x3d-public] X3D and VRML for multiuser worlds
>>>>
>>>> I am not sure what results you are referring to. Did I miss something?
>>>>
>>>>
>>>> From: x3d-public
>>>> [mailto:x3d-public-bounces at web3d.org[mailto:x3d-public-bounces at web3d.org]]
>>>> On Behalf Of Christoph Valentin
>>>> Sent: Friday, January 8, 2021 9:21 PM
>>>> To: 'X3D Graphics public mailing list'
>>>> Subject: Re: [x3d-public] Re: X3D and VRML for multiuser worlds
>>>>
>>>>
>>>> so basically you want to ignore my results?
>>>>
>>>> --
>>>> Diese Nachricht wurde von meinem Android Mobiltelefon mit GMX Mail
>>>> gesendet.
>>>>
>>>> Am 09.01.21, 01:07 schrieb GL
>>>> <info at 3dnetproductions.com[mailto:info at 3dnetproductions.com]>:
>>>> Christoph,
>>>>
>>>> Thank you for the clarifications and your general dedication. I
>>>> believe that little misunderstandings should be addressed before
>>>> they snowball into bigger misconceptions.
>>>>
>>>>
>>>>
>>>> > If we specify a general Network Sensor API, then content can run
>>>> > with any X3D Player that supports the Network Sensor API.
>>>>
>>>> If you read again my last paragraph, I try to make a distinction
>>>> between a multiuser client and a X3D player. In other words, the
>>>> player is not necessarily the client. It appears to be a common
>>>> misconception that the X3D player must also be the MU client, while
>>>> in truth it really doesn't have to. For the reasons previously
>>>> stated, I tend to prefer that the player does not in fact act as
>>>> the client.
>>>>
>>>>
>>>> > However, if I use the X3Daemon Client API, then I MUST use the
>>>> X3Daemon
>>>> > Server, because the protocol is proprietary.
>>>>
>>>>
>>>> That is precisely why I am here. I do NOT want the application
>>>> protocol to be proprietary. And the fact that we still don't have a
>>>> standard keeps me from moving forward, because any development
>>>> efforts I make may someday have to be rewritten once we do have a
>>>> standard. IOW, I am not a big fan of reworking systems. I'd rather
>>>> use open standards as early in the process as possible to
>>>> facilitate interoperability later.
>>>>
>>>>
>>>> > If the protocol was specified, then I could use ANY
>>>> > server with the X3Daemon Client.
>>>>
>>>>
>>>> Ideally, systems could interoperate, though there are other factors
>>>> to consider. For example avatars must login to authenticate their
>>>> identity and assets, consisting of information that may or may not
>>>> be available to a third party server. But yes, you get the general
>>>> idea.
>>>>
>>>>
>>>>
>>>>
>>>> > It is not sufficient to specify the
>>>> > fields and the behaviour of the NetworkSensor node. ...,
>>>> > but I had the feeling that you want to
>>>> > omit the specification of the protocol.
>>>>
>>>>
>>>> Read again, I was referring specifically to network protocols.
>>>> Still, at this early stage, I feel it may be a little premature to
>>>> get too involved with an application protocol, that until we get a
>>>> better grasp of what the requirements will be. For this reason, I
>>>> am of the opinion that fields and events should be specified first.
>>>> Just so that we have something to build upon.
>>>>
>>>> Of the published work available in that regard, we have BS
>>>> Collaborate, DIS, and the Draft X3D Specification for
>>>> NetworkSensor. I think the first step would be to take these, see
>>>> what they have in common, and go from there for deeper analyses.
>>>>
>>>> Once we have that settled, IMO, only then should we turn to discuss
>>>> an application layer protocol and its ramifications. GL
>>>>
>>>>
>>>>
>>>> > -----Original Message-----
>>>> > From: x3d-public
>>>> [mailto:x3d-public-bounces at web3d.org[mailto:x3d-public-bounces at web3d.org]]
>>>> On Behalf Of
>>>> > Christoph Valentin
>>>> > Sent: Friday, January 8, 2021 5:09 PM
>>>> > To: X3D Graphics public mailing list
>>>> > Subject: Re: [x3d-public] X3D and VRML for multiuser worlds
>>>> >
>>>> > Dear Gina Lauren
>>>> >
>>>> > Please find some feed back *inline*.
>>>> >
>>>> > Generally, please do not judge too hard, I'm not a native speaker
>>>> and still
>>>> > some of my wordings do not fit to the real intention.
>>>> >
>>>> > Kind regards,
>>>> > Christoph
>>>> >
>>>> >
>>>> >
>>>> >
>>>> ------------------------------------------------------------------------
>>>> > >You want to lock in your users. That's not the spirit of open
>>>> source.
>>>> >
>>>> > For once I was beginning to open up about the inner workings of a
>>>> multiuser
>>>> > system, but surprisingly, you apparently don't want to hear about
>>>> it. It is
>>>> > difficult to talk about open standards for a NSN if we can't refer to
>>>> > actual implementations. It's not like there are a lot of them
>>>> around..
>>>> > [CV]: I should not have written this. However, I was a little bit
>>>> > impatient, because I have been preaching for years and years that the
>>>> > protocol itself must be specified. It is not sufficient to
>>>> specify the
>>>> > fields and the behaviour of the NetworkSensor node. Maybe I did
>>>> not read
>>>> > your words sufficiently thoroughly, but I had the feeling that
>>>> you want to
>>>> > omit the specification of the protocol.
>>>> >
>>>> > Also, who said anything about open source being a requirement? I was
>>>> > actually volunteering closed source information for the benefit
>>>> of an open
>>>> > standard. If you can't see that I was actually "giving" something
>>>> to the
>>>> > community.. then perhaps I am wasting my time???
>>>> > [CV]: Here I used "open source" and meant "open protocols", sorry, my
>>>> > mistake. And, yes, I also "gave" a lot. Using too much time for
>>>> my hobbies,
>>>> > was one major reason, why my wife left us in 2015 (afterwards the
>>>> SrrTrains
>>>> > v0.01 project fell into hibernation mode due to lack of resources).
>>>> >
>>>> > Finally, if you would like to discuss an application layer
>>>> protocol, maybe
>>>> > look into work that has been done in the past referred to as vrtp
>>>> and x3dp.
>>>> > Not much, but a starting point. So far I have only heard vague
>>>> comments
>>>> > about SCTP, UDP, etc. (see below)
>>>> > [CV]: I am sure that many people have contributed many parts of
>>>> the puzzle.
>>>> > Now we need somebody, who fits all together (that's not me, is it?)
>>>> >
>>>> ------------------------------------------------------------------------
>>>> >
>>>> >
>>>> >
>>>> >
>>>> >
>>>> >
>>>> >
>>>> ------------------------------------------------------------------------
>>>> > > [CV]: I never suggested to specifiy the transport protocol
>>>> (http, rtp,
>>>> > > sctp, tcp, msrp, sip, xmpp, ........).
>>>> >
>>>> > hhhmmm.. I'm confused, what is this about???
>>>> > [CV]: Let's assume, we specify an "Application Layer Protocol"
>>>> (let's call
>>>> > it ALP in the sense of a "working title"). Probably the ALP will
>>>> consist of
>>>> > the definition of a few PDUs (e.g. in XML, JSON, YAML or similar
>>>> syntax).
>>>> > Now we have to define, how the PDUs have to be transmitted over the
>>>> > network. Will they be sent as payload in http messages (in the
>>>> body)? Will
>>>> > they be sent as payload in SIP messages (in the body)? Will they
>>>> be sent
>>>> > directly over tcp connections?
>>>> > To get historically: at the beginning of the IETF they had a great
>>>> > movement. You could get T-Shirts with the meme "IP over
>>>> everything". IP
>>>> > should connect any network with any network, building the
>>>> Inter-network. So
>>>> > they had to write one RFC for each L2 protocol in order to
>>>> specify, how IP
>>>> > has to be transported over any L2 link/network.
>>>> > I am dreaming of an "ALP over everything" movement.
>>>> >
>>>> >
>>>> ------------------------------------------------------------------------
>>>> >
>>>> >
>>>> >
>>>> >
>>>> ------------------------------------------------------------------------
>>>> > >[CV]: SCTP and UDP are members of the TCP/IP protocol family.
>>>> UDP is as
>>>> > >old as TCP, just simpler. SCTP is younger. It tries to merge
>>>> advantages
>>>> > >of both TCP and UDP and was originally invented to transport SS7
>>>> protocols
>>>> > >(SIGTRAN). SCTP supports 64k streams per association, what
>>>> perfectly fits
>>>> > >to our needs, imho
>>>> >
>>>> > Why are you trying to lecture me about network protocols? And
>>>> what is it
>>>> > exactly that you are saying or not saying, I find rather
>>>> perplexing and
>>>> > fail to see the relevancy. Let's keep going...
>>>> > [CV]: I thought you wrote "SCTP is not TCP/IP". I want to stress
>>>> that SCTP
>>>> > actually IS TCP/IP
>>>> >
>>>> ------------------------------------------------------------------------
>>>> >
>>>> >
>>>> >
>>>> >
>>>> ------------------------------------------------------------------------
>>>> > >[CV]: Actually I suggested to specifiy ONE AND ONLY ONE
>>>> application layer
>>>> > protocol,
>>>> >
>>>> > No-one is questioning this as far as I know. Isn't that precisely
>>>> what we
>>>> > are trying to do?
>>>> > Why are you augmenting this in my comments?
>>>> >
>>>> > [CV]: (see above) Maybe I did not read your words sufficiently
>>>> thoroughly,
>>>> > but I had the feeling that you want to omit the specification of the
>>>> > protocol.
>>>> >
>>>> ------------------------------------------------------------------------
>>>> >
>>>> >
>>>> >
>>>> >
>>>> ------------------------------------------------------------------------
>>>> > >[CV]: The API (i.e Network Sensor) must be specified to run ONE
>>>> content
>>>> > with ANY X3D Player.
>>>> >
>>>> > Let's be careful here. The X3D player does not necessarily need
>>>> to have
>>>> > agency over the application protocol. For example the X3Daemon client
>>>> > (sorry to bring it up) is entirely separate from the player other
>>>> than for
>>>> > interpreting ECMAScripts and rendering the results to screen.
>>>> IOW, the
>>>> > X3Daemon client can theoretically run in any X3D player,
>>>> regardless of
>>>> > internal multiuser coding, as long as ECMAScript (JavaScript) is
>>>> supported.
>>>> > This makes it very easy for authors to script avatar and object
>>>> behaviors,
>>>> > since it provides direct access to X3D nodes. It is also a reason
>>>> why we
>>>> > need to define a NetworkSensor node as part of the X3D standard.
>>>> > [CV]: That's exactly what I am saying: you specified your
>>>> X3Daemon client
>>>> > API, so a content that uses that API, can theoretically run with
>>>> ANY X3D
>>>> > Player (that the X3Daemon client supports). If we specify a
>>>> general Network
>>>> > Sensor API, then content can run with any X3D Player that
>>>> supports the
>>>> > Network Sensor API.
>>>> > However, if I use the X3Daemon Client API, then I MUST use the
>>>> X3Daemon
>>>> > Server, because the protocol is proprietary. If the protocol was
>>>> specified,
>>>> > then I could use ANY server with the X3Daemon Client. It's
>>>> similar with BS
>>>> > Contact and BS Collaborate.
>>>> > Most customers are very sensitive about getting locked in. No
>>>> matter if
>>>> > open source or closed source. We (my employer) made this
>>>> experience with
>>>> > railway operators, too.
>>>> >
>>>> ------------------------------------------------------------------------
>>>> >
>>>> >
>>>> > GL
>>>> >
>>>> > ________________________________________________________
>>>> > * * * Interactive Multimedia - Internet Management * * *
>>>> > * * Virtual Reality -- Application Programming * *
>>>> > * 3D Net Productions
>>>> 3dnetproductions.com[http://3dnetproductions.com
>>>> <http://3dnetproductions.com>[http://3dnetproductions.com
>>>> <http://3dnetproductions.com>]] *
>>>> >
>>>> >
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> x3d-public mailing list
>>>> x3d-public at web3d.org[mailto:x3d-public at web3d.org]
>>>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>>>> <http://web3d.org/mailman/listinfo/x3d-public_web3d.org>[http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>>>> <http://web3d.org/mailman/listinfo/x3d-public_web3d.org>]
>>>> _______________________________________________ x3d-public mailing
>>>> list x3d-public at web3d.org[mailto:x3d-public at web3d.org]
>>>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org_______________________________________________
>>>> <http://web3d.org/mailman/listinfo/x3d-public_web3d.org_______________________________________________>[http://web3d.org/mailman/listinfo/x3d-public_web3d.org_______________________________________________
>>>> <http://web3d.org/mailman/listinfo/x3d-public_web3d.org_______________________________________________>]
>>>> x3d-public mailing list
>>>> x3d-public at web3d.org[mailto:x3d-public at web3d.org]
>>>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org_______________________________________________
>>>> <http://web3d.org/mailman/listinfo/x3d-public_web3d.org_______________________________________________>[http://web3d.org/mailman/listinfo/x3d-public_web3d.org_______________________________________________
>>>> <http://web3d.org/mailman/listinfo/x3d-public_web3d.org_______________________________________________>]
>>>> x3d-public mailing list
>>>> x3d-public at web3d.org[mailto:x3d-public at web3d.org]
>>>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>>>> <http://web3d.org/mailman/listinfo/x3d-public_web3d.org>[http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>>>> <http://web3d.org/mailman/listinfo/x3d-public_web3d.org>]
>>>>
>>>> _______________________________________________
>>>> x3d-public mailing list
>>>> x3d-public at web3d.org
>>>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>>>> <http://web3d.org/mailman/listinfo/x3d-public_web3d.org>[http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>>>> <http://web3d.org/mailman/listinfo/x3d-public_web3d.org>]
>>>> _______________________________________________ x3d-public mailing
>>>> list x3d-public at web3d.org
>>>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>>>> <http://web3d.org/mailman/listinfo/x3d-public_web3d.org>
>>>> _______________________________________________ x3d-public mailing
>>>> list x3d-public at web3d.org
>>>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>>>> <http://web3d.org/mailman/listinfo/x3d-public_web3d.org>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20210125/ff7e1805/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kmlcjddfiimgjacf.png
Type: image/png
Size: 240041 bytes
Desc: not available
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20210125/ff7e1805/attachment-0001.png>
More information about the x3d-public
mailing list