Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Consideration of wwwivi hostname #223

Closed
anawhj opened this issue Jul 13, 2017 · 40 comments
Closed

Consideration of wwwivi hostname #223

anawhj opened this issue Jul 13, 2017 · 40 comments
Labels
VISS

Comments

@anawhj
Copy link
Member

anawhj commented Jul 13, 2017

As far as I know, wwwivi has been one of the major issues until even recently (e.g. Mozilla's objection). It allows clients such as web app, native app, and embedded(in IVI) app to connect to the WebSocket server in IVI system to get/set/sub a data. I have a few concerns about it, so put some opinions and suggestions as follows:

1. Problems
wwwivi is a hostname like localhost that can be mapped to '127.0.0.1', so wwwivi could be mapped to some IP and port to locally access the WebSocket server in IVI system. '192.168.0.0/16' is commonly used as the local gateway(router) address. In case of IVI system, the address could be mapped to wwwivi with 443 port depending on the IVI system local network policy. For the purpose, wwwivi can be used to connect to IVI system locally so that we could make some great demo using the keyword. But the problem is how wwwivi keyword can be looked upon with favor from other standards(IETF, GENIVI), car venders, and any other related field experts. In the traditional network theory, a fair number of people are most likely unfavorable stance about a wwwivi usage as a new GTLD due to several reasons (mozilla's comment). In addition to the issue above, there would be more concerns about a self signed SSL certificate, related security issues. While our specifications proceed to be formal recommendation, we should receive reviews from external stakeholders. So we should carefully handle major issues including wwwivi that is referred in VISS/VIAS.

2. Alternatives
I can come up with the following a couple of alternatives to mitigate the problem. If any reasonable candidate, we can develop the details.

  1. add a discovery phase
    To use wwwivi, the application should run on same local network with IVI system. IEEE 802.11(Wi-Fi) would be one of the candidates to put on the local network with IVI system. In the same local network, we can use a discover protocols like SSDP, mDNS, so we can add this phase before a connection to IVI system. In W3C Second Screen CG, Open Screen Protocol has been developed since early of this year. It allows user agent to send and receive a discovery packets to connect between devices. We can join the activity or refer the technical approach of the group.

  2. put it on 'out of scope'
    We can put wwwivi on 'out of scope'. It means wwwivi could be referred as optional, not required in the specification. In this case, there would be no oppositions though our specifications as standards would have less meaningful,

3. Naming
If we would like to stick to wwwivi for the time being, I think the terminology would be changed. The reason, it could be used in native app, embedded(in IVI) app using WS protocol, so the 'world wide web' doesn't fit for the purpose. Web Sockets have been embedded in all browsers, but it would be difficult to see as using only for the Web. I came up with some other alternatives as follows, but it would be less important than above issues.

  • ivihost (as an IVI system unit)
  • carhost (as a physical unit)
  • wsshost (for a more general term)
@rstreif
Copy link
Contributor

rstreif commented Jul 13, 2017 •
edited
Loading

@anawhj Thank you for your feedback. It is very much appreciated. I am hearing the concerns about the GTLD (Generic Top Level Domain). As far as the possible solutions are concerned:

  • Discovery Phase - I prefer to stay away from discovery. It complicates the implementation and puts overhead on the protocol for a thing that should actually be rather simple.

  • Out of Scope - The issue with that is that it is counter standardization. We would want web app developers to develop their app so that it could potentially run on any vehicle. If we say the FQDN is out of scope then we are hindering adoption.

  • Naming - I am amicable to change the name to a subdomain of w3.org or another TLD that would work well for this purpose e.g. vis.w3.org.

@anawhj
Copy link
Member Author

anawhj commented Jul 13, 2017

I agree the concerns about both discovery and out of scope. Does a subdomain of w3.org means 'wss://vis.w3.org' allows web app to locally connect to VIS in the car without a request to a external server (w3.org)?

@rstreif
Copy link
Contributor

rstreif commented Jul 14, 2017

Does a subdomain of w3.org means 'wss://vis.w3.org' allows web app to locally connect to VIS in the car without a request to a external server (w3.org)?

vis.w3.org would need to be resolved into an IP address. That can be done locally (for Linux/Unix typically /etc/hosts) and telling the resolver to use the local files first (for Linux/Unix typically set with /etc/nsswitch.conf). I admit hijacking a TLD and adding a subdomain that's locally resolved might not be very elegant.

@sou3ilow
Copy link

sou3ilow commented Jul 14, 2017 via email

@rstreif
Copy link
Contributor

rstreif commented Jul 14, 2017

If the owner of w3.org hopes, vis.w3.org can be resolved to 127.0.0.1 by a
global DNS. CAs are allowed to issue certificate for this domain name, so
we don't need self signed certificate. That is I asked an d an expert
answered at a breakout session in the last TPAC.

That could be the default solution to resolve the name to localhost IP. It then could still be overwritten by a local configuration if an implementer chooses to do so.

@wzr1337
Copy link

wzr1337 commented Jul 14, 2017 via email

@sou3ilow
Copy link

sou3ilow commented Jul 15, 2017 via email

@anawhj
Copy link
Member Author

anawhj commented Jul 17, 2017

There would be no case to resolve from TLD to IP locally without a DNS involvement from what I know, even though it could technically be operated in VIS. In case of resolving from TLD to 127.0.0.1 by a global DNS, it could not be a common approach especially from a standard point of view regardless of the certificate issue, even if it's technically available.

I think the following precondition should be considered before our discussion:

  • The WS connection should be available, even offline (no support of DNS)
  • External devices could be available to connect to VIS (If not, few meaningful as a standard)

I would suggest that the related research could be found to review these issues (other groups in W3C/IETF, OEMs and Tier 1s' approach).

@sou3ilow
Copy link

sou3ilow commented Jul 17, 2017 via email

@drkevg
Copy link
Contributor

drkevg commented Jul 18, 2017

In general, a particular vehicle instance will not be contactable until it first reaches out to a well known endpoint in the internet. This is because it will typically be assigned a new IP address either by the Mobile Network Operator (MNO) or via a local WiFi network when it first connects to these networks, and of course a vehicle could lose connectivity and be assigned a different IP address during a journey.

In part for this reason, the model for the VISS WebSocket server is that is accessible from in-vehicle clients only, but of course, there is nothing to stop an in-vehicle agent or other in-vehicle software service acting as a bridge/proxy routing requests between the VISS server and any offboard entity (that by some means e.g. the agent reaching out to it, has the vehicle's current IP address).

Reason for choosing wwwivi was that there could be other WebSocket servers implemented at other endpoints on the same vehicle, so we wanted a way of 'finding' the VISS WebSocket server.

Agree with Rudi that we could have a different name e.g. w3civi and like Rudi, I would prefer not to go down the route of using a discovery service (unless we have to ) or reducing level of standardisation by making name optional.

@peterMelco
Copy link
Contributor

So, have we reached consenus on this one ? Continue with wwwivi or change to W3civi ?

@peterMelco peterMelco added the VISS label Sep 5, 2017
@anawhj
Copy link
Member Author

anawhj commented Sep 5, 2017

In a couple of WG calls, this issue was briefly discussed but it was difficult to reach consensus. I totally agree to stay it away from both adding discovery phase and specifying out of scope. The remaining concern is wwwivi naming for which several alternatives were mentioned in this thread as follows.

  • vis.w3.org (that could be resolved to 127.0.0.1 by global DNS or local resolver, but it has a problem that external device couldn't access to the VIS in the car using the domain address. Who can resolve it in the external device?)
  • wwwivi (as it is)
  • ivihost (as I suggested on the basis of meaning and nuance. The meaning is based on a way of finding the VISS WebSocket server)

The wwwivi hostname gives a way of finding the VISS WebSocket server as @drkevg mentioned, and I surely understand the role of wwwivi. But I think it would be a constrained alignment between www(world wide web) and WebSocket(not HTTP for now) from the wording point of view. In addition, VISS was designed for not only web-based platforms, but native platforms. So I prefer not to use www even though wwwivi looks like simple and intuitive from a personal view and there seems no great candidates.

I listed several candidates to indicate the VISS WebSocket server with wss:// prefix as follows.

  • wss://wwwivi
  • wss://w3civi
  • wss://ivihost
  • wss://viss
  • wss://vwss
  • wss://vis.w3.org

Who is the handsome address? It seems absolutely difficult to reach the decision(voting!), so I mentioned naming issue would be less important in the description of this thread. But we should prepare the reasonable evidences for VISS to CR against expected objections as we've already gotten before. The approach of hijacking a TLD might not be very elegant as @rstreif mentioned.

I would suggest that we can consider using .local suffix as a standard-based approach. I came up with the idea in the reserved domains section. localhost is one of the reserved domains. .local is also one of the reserved domains for link-local host names that can be resolved via the Multicast DNS name resolution protocol that should probably be managed by IVI AP(not sure). .local is specified in RFC6762, but I couldn't carefully read the document so I'm not sure it's right approach. If right, we can possibly replace wwwivi with ivi.local.

p.s. In the chapter 7 in VISS spec, wvss is mentioned as a subprotocol name. As far as I know, the subprotocol should be registered in IANA registry according to RFC6455. I checked the registry for WebSocket's subprotocol, but wvss dosen't exist there. I wonder who care this. In addition, I think chapter 7 of VISS spec looks like to be revised including clear definitions, acronyms, and roles of wwwivi, wvss.

@peterMelco
Copy link
Contributor

What we should not do is to have a name that in any way indicates where the server should actually be implemented. .To me .local does imply that the server resides on the IHU or at least locally in the Vehicle Network, and how weird it still may seem that it is not , it could in theory be implemented elsewhere.

@anawhj
Copy link
Member Author

anawhj commented Sep 7, 2017

@peterMelco As far as I know, vehicle WebSocket server should be on the IHU or internal somewhere in vehicle so that we can safely protect secure information provided by IVI(In-Vehicle Infotainment) system. As @drkevg mentioned above, some bypass methods like both in-vehicle agent and a bridge/proxy routing could be available to connect the vehicle WebSocket server from offboard entity, but I'm not sure why we should consider to put the server out of a vehicle.

.local-based approach isn't much different with wwwivi, but it has definite benefits of existing standard-based way and excluding TLD concerns.

@peterMelco
Copy link
Contributor

peterMelco commented Sep 7, 2017 •
edited
Loading

@anawhj Firstyly, I think it is a misunderstanding that this specification only targets infotaiment. It is a specification that standardise how to expose car signals. In my world IVI is one of many possible use cases. I do agree that for the traditional IVI system your argument makes sense for what our idea of an IVI system looks like today. However, I do believe that we not should make such assumptions when we don't need to.

@peterMelco
Copy link
Contributor

So, then I guess that I really don't like IVI either since :).
One other question is how to treat multiple instances of the server in the vehicle network. There are use cases where you could have various ECUSimplementing the VISS specification, residing on the same network. If someone would decide to host the server outside the vehicle network and expose signals on the internet how should we treat that then. Having your own domain name would then be a violation of the specification. Having said that the idea with .local have its benefits as mentioned by @anawhj

So questions:

  1. How to treat multiple instances of the server and still compying with the spec ?

  2. How to treat servers hosted in some kind of cloud ?

  3. Come up with a name that is not limiting the use case. E.g not IVI maybe viss.local.

@anawhj
Copy link
Member Author

anawhj commented Sep 12, 2017

@peterMelco It seems to have a discussion in public-automotive.
I think the following link could describe the answer for your questions.
https://lists.w3.org/Archives/Public/public-automotive/2017Sep/0016.html

@acrofts84
Copy link
Contributor

Believe that we need to keep sub-protocol (as this is associated with a specific VSS version), but re. hostname 'wwwivi', could the best solution be to simply state that this will be defined by the implementer? [Adam & Kev]

@drkevg
Copy link
Contributor

drkevg commented Sep 20, 2017

In response to action on WG call on 19th to add example scenario where vehicle network could need to support more than one VIS Server.

Scenario: More than one product team decides to implement VIS Server
a) Team developing the instrument cluster (that includes speedometer, RPM meter etc) decides to include a VIS Server on the Instrument Cluster Electronic Control Unit (ECU) to obtain data to display to user in speedometer control etc.
b) Independently, the team developing an Infotainment System decide to implement the VIS Server to obtain vehicle data to be used in Apps running in the Infotainment system.
c) Team developing a Gateway around the (part of) CAN network decide to use VIS Server to encapsulate CAN signals and to manage access to signals and data
d) Cluster, Infotainment System and Gateway are all on same network (for new vehicle models), but these components are introduced at different times onto new vehicle lines. So, some models have only one, some two, some all three. This means that e.g. Cluster team implements its own VIS server on the Cluster ECU because they don't want to wait until the team developing the Gateway introduce their VIS Server (which might be a year later).
e) Client on Cluster ECU (e.g. that provides speedometer UI) needs to connect to VIS Server on Cluster
f) Client on Infotainment System (e.g. an App) wants to connect to VIS Server on Infotainment System
g) Client running on some other ECU on same vehicle network that Cluster ECU, Infotainment ECU and CAN Gateway ECU wants to connect to a VIS Server and wants to be able to specify a particular one e.g. the Gateway ECU VIS Server.

This scenario is somewhat artificial, but the main point is that believe we need to enable a client to connect to a VIS Server where there is potentially more than one available on the vehicle sub-net.

@triblondon
Copy link

triblondon commented Sep 26, 2017 •
edited
Loading

The TAG was asked to take up this issue by Ted Guild and we had a lively discussion about it at our Nice F2F. We're encouraged by the possibility of using web technologies in automotive environments to make vehicles part of the open web in an appropriately secure way, and our feedback can be summarised as:

  • Web browsers embedded in IoT devices tend to have poor standards support when compared with browsers in general purpose computers such as laptops, tablets and smartphones. We understand the challenges facing manufacturers in shipping an up to date browser, and have captured our views on this in our finding on the evergreen web. In this case, we feel that an assertion that a vehicle's web stack will never interact with external content or devices is perilous, and if we accept that such interaction is likely and even desirable, then it is important that everything the vehicle's web stack does is web-compatible and evergreen.
  • Given the above point, the choice of the wwwivi hostname is unwise. For VSS servers on the vehicle's local network which are not visible on the public internet, RFC6762 provides for .local and we believe it would be appropriate to use it here. This would make the VSS APIs accessible to both the vehicle's built in browser, if it has one, and also to the user's own devices, where they are securely connected to the same local network via a mechanism such as USB, Bluetooth or Wifi. We also imagine a compelling use case for exposing the VSS on the public internet (with appropriate authentication), in which case the vehicle manufacturer should register and adopt a public domain name
  • Multiple VSSes in the same vehicle is a great example of why using standard web architecture is the most compatible and future proof way forward. One could imagine base URLs differentiated by path, eg acmecar.local/vss/instruments and acmecar.local/vss/ice, if the servers are provided by a single computing unit, or by subdomain, eg vss-instrumentation.acmecar.local if the vehicle has totally separate VSS hardware for each function.
  • While it's reasonable to define a JavaScript API that makes it easier to consume VSS APIs in the browser, we are nervous of premature standardisation here. It may be worth considering an initial implementation using generic networking APIs such as fetch and WebSocket, and allowing the developer community to build their own higher level abstractions in competing client libraries. The winner might then influence a more informed design for an API native to the web platform.

We also discussed the choice of websockets for the protocol and would like to understand more about the choices in the design of the protocol for the APIs. An explainer would be useful.

@anawhj
Copy link
Member Author

anawhj commented Sep 26, 2017

The feedback from TAG makes me clear with the great explanations. I have totally been thinking the same as the above points. Honestly, TV industry used to have the similar experience in trying to make unified APIs incl. connectivity with mobile for the compatibility. But it was very difficult to get the consensus among TV makers with web-based platforms. As the result, even now, web-based TV app developer should consider the specific guideline provided by each web platforms even though the app consists of HTML, CSS, and JavaScript, so that we couldn't catch the big advantage of the web. I really hope that W3C Automotive WG can make the meaningful standards for OEM vendors and (web) app developers.

As I see, one of VISS's major roles is to provide a standardized way to connect to VSS server. For the standardized way, we can define both (1) the unified address that can be accessible to VSS server, and (2) the relevant JS API. I think the unified address would be useful for developers, but regarding the relevant JS API, it seems premature status as @triblondon mentioned.

I'd like to put on two opinions while reminding the purpose of our works for vehicle standardization.

  • The proposed standard should be well-designed in consideration of existing standards. I guess OEM would provide a way for exposing the VSS on the public internet through their dedicated methods, and it's totally out of scope for standardization. On the other hand, we should be able to make the VSS APIs accessible to both a vehicle's built-in browser and user's own devices on the vehicle's local network, and it would totally be in scope for standardization. If we'd like to consider using .local-based dedicated address, then we should define a new API for using .local-based address. the .local-based address can't be put on new WebSocket(...). As far as I know, there seems no W3C standard API to handle the UDP socket even though a couple of specs tried to define the ways like NSD, Raw Sockets, which were deprecated in the old days.

  • The proposed standard should be easy to use. Otherwise, it would be difficult to accept from actual implementer. The current specifications(VISS/VIAS) seems to be written in consideration of the simple and easy to use. If only wwwivi issue can be resolved, we could settle it as a first phase. In the process of experimental implementation, we can elaborate the details later.

@martinthomson
Copy link
Member

I would add a personal observation to those of the TAG: use HTTPS. Every time we thought that it was sufficient to control access to the network to provide security, we've been sorry.

the .local-based address can't be put on new WebSocket(...).

That's not true. .local addresses are just like any other address. They have some rules for handling at the DNS layer in some special cases that you shouldn't care about (read the RFC), but nowhere else.

And please don't consider raw UDP. How about HTTP?

@anawhj
Copy link
Member Author

anawhj commented Sep 27, 2017

How about HTTP?

I totally agree that we should consider using the HTTP(S)-based approach. In W3C Automotive BG, the approach has been considered in RSI TF, and you can see the initial draft as follows.
https://www.w3.org/Submission/2016/SUBM-viwi-protocol-20161213/

And please don't consider raw UDP.

In new WebSocket(url), the url should be an address of WebSocket server. .local address can't directly indicate the WebSocket server, so .local can't be replaced with wwwivi. The request made by `.local' address would be handled with some rules at the DNS layer on the vehicle's local network.

I'm not telling the features for raw UDP in the web, because app developers shouldn't care the low-level network mechanism. What I want to say is that we need a new API, not using WebSocket() method if we'd like to use the .local-based address. The extension for WebSocket() interface could be a candidate solution while we should consider the WebSocket interface as a API layer as well as protocol layer , but it seems very difficult work.

In my opinion, there seems no great solution if we doesn't accept the .local-based approach. The new API would be necessary if we'd like to use the .local-based approach. I would suggest that the new API could be drawn as follows, but it has a very premature shape. The problem is where ivi.local can put.

// As-is (ivi.local can't be replaced with wwwivi)
var vehicle  = new WebSocket("wss://wwwivi", "wvss1.0");

// To-be (fetch would be replaced with a new API)
let vehicle;
fetch("ivi.local").then(wsAddr => {
  vehicle = new WebSocket(wsAddr, "wvss1.0");
}

@martinthomson
Copy link
Member

I don't understand the comment. new Websocket("wss://wwwivi") works just as well as new WebSocket("ivi.local"). The piece that .local adds to the stack of problems you need to solve is not that, but the discovery piece. You need to describe how to find the in-vehicle server because you can't just claim ivi.local. DNSSD is the usual process. I don't know how you intended to route packets to wwwivi, but I more or less assumed that there was a DNS server involved somewhere.

@sou3ilow
Copy link

sou3ilow commented Sep 28, 2017 via email

@drkevg
Copy link
Contributor

drkevg commented Oct 3, 2017

Can I clarify, is there a consensus emerging to specify (as the default) ivi.local instead of wwwivi but to specify that implementers could define in their documentation an alternative (to enable more than one VISS server to be on same network)?

@aShinjiroUrata
Copy link
Contributor

Hi.
Use of '-.local' based approach looks realistic and looks good.
I think, one remaining issue would be, when employing '-.local' approach, how to handle 'wss', which means how to issue legitimate certificate ( not like self signed certificate or certificate from private CA ).

However, I think this 'certificate for localnetwork' issue is a not-yet-solved problem and also not automotive specific issue.
So personally I think, WG may be able to leave this certificate issue unsolved and move on to VISS Recommendation and the certificate issue should be addressed at some other discussion.

@mnot
Copy link
Member

mnot commented Oct 3, 2017

Squatting on a hostname -- even if in .local -- isn't good practice, as @martinthomson pointed out earlier. You need a discovery mechanism (such as DHCP or DNSSD).

@tguild
Copy link
Member

tguild commented Oct 18, 2017

We discussed yesterday during the WG call, no concensus was reached. Most agree discovery is the right thing but it introduces complexity for the developer and may open up security concerns. Development hassle can be addressed with common library so each app doesn't have to do its own discovery. In the simplest and most common case of one service per vehicle, doing rediscovery on each reboot of the car seems like a waste. One idea would be an app installer stores zeroconf results as static conf. Some wonder if a static default fallback would be acceptable.

Minutes: https://www.w3.org/2017/10/17-auto.html

@mnot
Copy link
Member

mnot commented Oct 19, 2017

If you must have a static hostname, have you considered using one in w3.org or similar space? As long as you own the domain, it's not squatting.

@tguild
Copy link
Member

tguild commented Oct 19, 2017

That has come up and is a consideration.

@drkevg
Copy link
Contributor

drkevg commented Oct 20, 2017

We have been struggling for quite a few months to get agreement on how to resolve the hostname (wwwivi) issue (#223).

Can I suggest that we resolve the impasse by saying that the implementer will document how the hostname is obtained, but a default for the VIS Server that is hosted on the IVI ECU.

Hence, propose that we add statements like:

/* Start of change */
"A vehicle may have more than one VIS Server that can be accessed by a client running on an ECU connected to the in-vehicle network.

The implementer of a VIS Server will document how an in-vehicle client can obtain the hostname that is needed to connect to that VIS Server instance. This could be using a Discovery Service (that is outside of the scope of this specification) or by configuration.

By default, the VIS Server deployed on the In-Vehicle-Infotainment system will have the hostname 'ivi.w3.org.local' but the implementer may specify a different value'.
/* End of change */

We would then change our example statements to use 'ivi.w3.org.local' as hostname instead of wwwivi

I'm not entirely sure that adding a '.local' extension to 'w3.org' doesn't violate other conventions, but logically it takes account of the feedback on the issue (of not cyber-squatting and making clear that its a local name)

Believe that in practice an onboard client is likely to have a config file (or a Registry or similar) that can be used to define the runtime configuration, so if the default is not suitable it can be configured prior to deployment OR could make use of a Discovery Service if implementer has stated this will be available.

I didn't want to tightly couple the spec. to a particular Discovery protocol or mechanism (as these could evolve over time and couldn't think of a better compromise or route out of this issue - hope the group agrees to the above, but if it doesn't get consensus, very happy to consider other alternatives...

[Perhaps we can settle on this for now, and if there is strong views later about an alternative, we re-open the issue at that point]

@peterMelco
Copy link
Contributor

peterMelco commented Oct 20, 2017 via email

@anawhj
Copy link
Member Author

anawhj commented Oct 30, 2017 •
edited
Loading

I briefly followed the previous discussion in this thread and public-automotive mailing list. I'd like to summarize the current situation with my opinions so that it would be helpful for an agreement.

Specifying a static hostname for connecting to VIS Server (e.g. wwwivi)

The following statements would be important for making a decision (See Appendix G in RFC6762)

  • We recommend against using ".local" as a private Unicast DNS top-level domain.
  • We do not recommend use of unregistered top-level domains at all.

According to the guideline above, ".local" could be used for a discovery phase(multicast), but not for a static hostname(unicast), so the candidates for the static hostname is as follows (in order of a personal priority).

  • wss://viss.w3.org
  • wss://ivi.w3.org
  • wss://ivi.viss.w3.org

Discovery mechanism (e.g. mDNS) for searching the address of VIS Server

Using ".local"-based address, we can discover VIS Server to be connected locally. Looking closer, "abc.local" is basically resolved to 224.0.0.251 with 5353 port number while "abc" is added in the UDP header. The term like "abc" seems difficult to be standardized in consideration of the internal procedure while I couldn't find any relevant cases using the standardized term for ".local" yet.

Any DNS query for a name ending with ".local." MUST be sent to the mDNS IPv4 link-local multicast address 224.0.0.251 (page 5 in RFC6762)

In addition, the common discovery methods based on UDP couldn't likely guarantee the reliability between heterogeneous devices. As an exceptional case, Apple provides Bonjour service internally using mDNS for their products with an acceptable reliability, but in general, it would be difficult to assure the compatibility for the discovery between devices made by several manufacturer.

For an instance, in home network scenario, there have been several multi-screen use cases with TV and mobile using the local discovery phase, but most of them wouldn't be successful so far. I experienced DLNA, Smart TV Alliance, etc. more than a decade ago, but there were several problems such as difficult to use, unreliable connectivity, inconsistent compatibility.

In this background, I would suggest that the discovery-based approach put out of scope in VISS spec. Meanwhile, in Open Screen Protocol, there has been some discussion how the Web can support the discovery functionality. We could align the discussion with VISS, but it would spend a considerable time to make progress. (put it on the future work)

Multiple VIS Server in the same vehicle

We could consider several options as follows:

  • URLs differentiated by path (e.g. viss.w3.org/adas, viss.w3.org/cluster)
  • Subdomain (e.g. adas.viss.w3.org, cluster.viss.w3.org)

In my opinion, I'm not sure app developer should specify the location of VISS. If there are several options for the VIS Servers, the selection UI could be provided in the system(eg. browser), not app developers. It seems to depend on the environments (in-vehicle app, portable device app), but I don't know the exact situation since I'm not familiar with the whole automotive system.

Certificate for a secure connection in a local network

It is not a problem only for automotive, but for several industries (e.g. WoT). In VISS, this issue could be specified as a note to be solved in other space of W3C. I hope the following CG would provide a great way to handle this issue (HTTPS in local Network CG: https://www.w3.org/community/httpslocal).

===
I hope #223 issue could be finalized sometime around next week in TPAC. Thanks for the valuable comments from @martinthomson, @mnot, @triblondon. I look forward to seeing their opinions for the explanation above.

@igarashi50
Copy link

: @anawhj It is not a problem only for automotive, but for several industries (e.g. WoT).

I agree.

The UC-4 of the HTTPS in Local Network CG is similar to the use case about a car dashboard monitor. Also, the VIS server could be on local network in a vehicle as the other use cases of the CG. I think the solution should be a common to the Open Web.

UC-04: Embedded system monitoring and controlling for display-capable devices
https://github.com/httpslocal/usecases/blob/master/UseCases.md

@drkevg
Copy link
Contributor

drkevg commented Nov 7, 2017

As many contributors on this thread have pointed out , the problem of finding or discovering service endpoint is a general problem and not one that is particular to VISS. The same problem affects WoT, TV etc

Also, the problem is of course logically recursive, in the sense that you need to define (one or more) standard mechanism(s) to reach something that is then capable of resolving the question 'how do I connect to X'

I would suggest that the VISS should not try to solve this problem, and that for the VISS we simply specify:

'The implementer of a particular VIS Server instance will define how to connect to that VIS Server.'

At a later point, the VISS can potentially be updated to reference an agreed approach for resolving how to connect to a particular instance, ideally referencing the same W3C approach that WoT, TV etc uses.

[Agree that it is not ideal, but the HTTP protocol effectively takes this approach. The W3C didn't previously try to define in the HTTP spec. how to find every Web Server / Web Application instance that could be connected to...]

@peterMelco
Copy link
Contributor

peterMelco commented Nov 7, 2017 via email

@anawhj
Copy link
Member Author

anawhj commented Nov 22, 2017

We've investigated wwwivi issues for more than four months so that we might make a decision from a couple of mailing lists(public, private) and TPAC meeting. The major changes could be listed as follows.

  • eliminate wwwivi as an address to connect to VIS server (wss)
  • specify a discovery mechanism as a guideline (configuration in an app package manifest)
  • put unsolved issues on the future work such as certificate for a secure channel, multiple VIS servers

Once someone put the updates in VISS spec (probably VIAS as well), the issue would be closed.

@peterMelco
Copy link
Contributor

Whats going on with this ? Who is up for specifying the guidline ?

@drkevg
Copy link
Contributor

drkevg commented Dec 19, 2017

Added paragraph (based on wording provided by Ted) summarizing the discussion within the WG and after consultation with the Technical Architecture Group. Paragraph makes clear that determining the hostname will be implementation specific using either a discovery mechanism or by configuration and that the value 'wwwivi' should be treated as an example.

@drkevg drkevg closed this as completed Dec 19, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
VISS
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests