RE: Attempting to achieve consensus re. wwwivi issue (#223)

Hi Ted,

Do you mean that the director approved to resolve "<some_fixed_hostname>.w3.org" to 127.0.0.1? If so, that sounds fine for now. There are few ways to include https/wss into a local system without using a self-signed certificate, which may be blocked by TAG.

We need some kind of compromise. If using Let's encrypt, anyone can obtain an authentic certificate for <some_fixed_hostname>.w3.org.
So the certificate for the domain is useless to authenticate the VISS provider. But it still keeps communication channel secure and allows us to mix vehicle information with resources from external origins.

"<some_fixed_hostname>.w3.org" does not support (1)multiple VISS in a network or (2)access from in-car smartphone/tablet from the spec. However it won't be a obstacle for them as well. I believe other specs will realize these use cases.

Regards,
Junichi Hashimoto

-----Original Message-----
From: Ted Guild [mailto:ted@w3.org] 
Sent: Friday, October 27, 2017 4:31 AM
To: Gavigan, Kevin
Cc: Gunnar Andersson; Peter Winzell; Streif, Rudolf; Adam Crofts; 橋本 隼一; Lovene Bhatia; Magnus Gunnarsson; Mark Nottingham; Mike Aro; Shinjiro Urata; public-automotive
Subject: Re: Attempting to achieve consensus re. wwwivi issue (#223)

Thank you Kevin for the perspective that helps. While unlikely it is still conceivable an app would want to connect to more than one service.

I have provisional approval from the W3C Director for a w3.org hostname or subdomain pending a formal request. We should settle on name[s] as Gunnar suggested via a poll once we have suggestions. We will likely want to create a real DNS record and page residing at it explaining the purpose. That is something I would do.

On Wed, 2017-10-25 at 15:41 +0100, Gavigan, Kevin wrote:
> Hi Ted,
> 
> Please see below for my comments in blue
> 
> >> What I think would help would be to have a better understanding on
> why we might have multiple VISS and whether an application is expected 
> to communicate with more than one.
> 
> Imagine the team creating the new 'Hi Line' Deluxe infotainment system 
> decide to include a VIS Server in the infotainment system.
> This system will be released in 19 Model Year (MY) on _some_ vehicles 
> only
> 
> Imagine also that  a few months later, the team that is responsible 
> for developing the Instrument Cluster decides to design a new cluster 
> 'back-end' ECU to be used by _all_ cluster designs (regardless of the 
> particular UI for a particular cluster) from 21 Model Year onwards, 
> and that they think that the W3C Spec and VIS Server idea is brilliant 
> and so decide to use a VIS Server running on the cluster ECU to obtain 
> processed signals
> 
> The Cluster team cannot use the Infotainment system VIS server because 
> the cluster will be in all vehicles but the Deluxe infotainment system 
> will only be in some vehicles.
> The Infotainment team cannot use the VIS Server in the Instrument 
> Cluster because they want to launch in 19 MY and the Cluster won't be 
> available until 21 MY
> 
> In general, it's probably unlikely that a single App would try to 
> connect to both. More typically, would be an app installed on IVI ECU 
> connects to VIS Server on IVI and similarly an app on the cluster ECU 
> connects to VIS Server on the cluster - but it is possible that an App 
> on some other ECU might want to access one or other of them (via the 
> vehicle's in-vehicle ethernet network)
> 
> >> I'm not sure who proposed wwwivi initially but agree ivi in the
> name is limiting. This service can be used by the dashboard, IVI, may 
> be useful for things like ADAS and RVI, data sampling for V2X or 
> insurance. and have apps connect from smartphones, tablets and other 
> devices in the vehicle.
> 
> If think wwwivi came out of a group discussion at one of the F2F 
> meetings (possibly the one in Portland)
> 
> If as a group, we decide we want to specify a suggested default (and 
> we wanted the default to include w3.org or w3.org.local), we could 
> follow e.g. the following scheme:
> 
> We could have a default naming scheme of either 
> <location>.<spec>.w3.org or <location>.<spec>.w3.org.local  If we 
> assume that 'w3.org.local' or 'w3.org' part is denoted by <suffix>, we 
> could then have suggested defaults like the following:
> 
> ivi.viss.<suffix>          to specify default value for VIS Server on 
> IVI ECU cluster.viss.<suffix>   to specify default value for VIS 
> Server on cluster ECU adas.ivi.<suffix>        to specify default 
> value for VIS Server on adas ECU <y>.ivi.<suffix>         to specify 
> default value for VIS Server on <y> ECU ...
> 
> The same conceptual issue will affect 'finding' local RVI services - 
> once RVI is available, this could then have as defaults:
> 
> ivi.rvi.<suffix>          to specify default value for VIS Server on 
> IVI ECU cluster.rvi.<suffix>   to specify default value for VIS Server 
> on cluster ECU adas.rvi.<suffix>        to specify default value for 
> VIS Server on adas ECU <y>.rvi.<suffix>         to specify default 
> value for VIS Server on <y> ECU ...
> 
> Personally, I don't have a strong view on whether we include a 
> suggested default or not, but I would suggest that if we can't agree, 
> we de-scope this whole debate and simply state that "the implementer 
> of a VIS Server will document how to connect to the VIS Server".
> [Which could of course be via a Discovery mechanism or by 
> configuration]
> 
> [Unfortunately Adam and I will not be able to attend next months F2F, 
> but if it can't be resolved in github/email, it would be great if at 
> the F2F this could be made a priority - as it is the only issue 
> preventing the spec from moving forward...]
> 
> Regards,
> 
> Kev
> 
> 
> Kevin Gavigan BSc, MSc, PhD, MCP, MCTS Software Architect Connected 
> Infotainment Electrical, Electronic and Software Engineering (EESE) 
> Jaguar Land Rover
> 
> Mobile: 07990 084866
> Email: kgavigan@jaguarlandrover.com
> 
> Office address:
> GO03/057 • Building 523, Gaydon • Maildrop: (G03) Jaguar Land Rover • 
> Banbury Road • Gaydon • Warwick • CV35 0RR
> 
> On 24 October 2017 at 19:52, Ted Guild <ted@w3.org> wrote:
> > Thank you Gunnar, some responses in-line.
> > 
> > What I think would help would be to have a better understanding on 
> > why we might have multiple VISS and whether an application is 
> > expected to communicate with more than one.
> > 
> > We should also try to envision the OEM app marketplace. Instead of 
> > trying to discover services for a given vehicle platform, the 
> > marketplace could provide configuration for that year, make and 
> > model on which service[s] a specific app is expected to interact 
> > with.
> > This
> > is what I meant earlier by provisioning.
> > 
> > On Mon, 2017-10-23 at 12:18 +0200, Gunnar Andersson wrote:
> > > On Sat, 2017-10-21 at 12:24 +0000, Peter Winzell wrote:
> > > > I have consensus :). I completely agree with Kevin. Oems will 
> > > > follow and make their own choices and I think that there is high
> > probability
> > > > that if
> > > > we specify a server name - whatever it might be - it will never
> > be
> > > > used.
> > >
> > > I wouldn't go that far.
> > >
> > > First, it would be a recommendation, in my opinion.
> > >
> > > Second I think standards do help, because in communication an OEM
> > can
> > > then
> > > say "just follow the standard as written in chapter 5.6".  And
> > some
> > > will do
> > > that.  It's not bad to have a default, and then if OEMs want to
> > do
> > > something
> > > different, they specify that separately.
> > >
> > > I may have missed if it was given in discussions - if so could 
> > > someone repeat for me the rationale for including "ivi" in the 
> > > name?  The specification isn't written to be IVI specific, is it?   
> > > I think
> > if
> > > the key
> > > point is that it is a "local" server on the same computing unit
> > as
> > > the
> > > application making the request, just indicate that.
> > 
> > I'm not sure who proposed wwwivi initially but agree ivi in the name 
> > is limiting. This service can be used by the dashboard, IVI, may be 
> > useful for things like ADAS and RVI, data sampling for V2X or 
> > insurance.
> > and
> > have apps connect from smartphones, tablets and other devices in the 
> > vehicle.
> > 
> > > Why not simply "viss"?   If it's a W3 subdomain, how about
> > viss.w3 or
> > > visslocal.w3... assuming it is the _recommended_ name for a
> > locally
> > > hosted
> > > server?  (A simple poll would probably resolve the naming
> > question)
> > 
> > I like viss better but since VISS is to be followed shortly by RSI 
> > maybe something appropriate for either.
> > 
> > Today's schedule got jumbled with others' meetings and my attempt to 
> > get time on decision from W3C regarding a hostname is pending.
> > 
> > > Finally, I agree with where the discussion was going last time:
> > >
> > > First, these are separate things:
> > >
> > > 1) Chapter describing a recommended fixed name for a local VISS 
> > > server, (and that the underlying system will likely translate it 
> > > with a static
> > IP
> > > mapping).
> > >
> > > 2) Chapter describing the recommended local service name and the 
> > > usage of mDNS discovery.  Including an impmlementation note to 
> > > take great
> > care
> > > of
> > > security issues, spoofing in particular.
> > >
> > > Second, the specification could include either one, two, or none
> > of
> > > these
> > > chapters.  They could also be added at a later time.
> > >
> > > My vote would be to include chapter 1 now and a single sentence
> > about
> > > mDNS
> > > discovery.  A separate instruction could be created to describe
> > how
> > > to
> > > implement mDNS in this context.
> > 
> > Until we understand the ramifications that would make sense.
> > 
> > > More below.
> > >
> > > >
> > > > lör 21 okt. 2017 kl. 04:26 skrev Gavigan, Kevin <kgavigan@jagua
> > rlan
> > > > drover.
> > > > com>:
> > > > > Hi Ted and Rudi,
> > > > >
> > > > > Thanks very much for your feedback - I guess we don't quite
> > yet
> > > > > have
> > > > > consensus :-)
> > > > >
> > > > > [From Rudi:]
> > > > > If I recall correctly we discussed a w3.org subdomain before.
> > I
> > > > > am not
> > > > > sure why it got discarded at the time. However, I am strongly
> > in
> > > > > favor
> > > > > of it. Let's move ahead with an Editors Draft with a w3.org 
> > > > > subdomain/hostname.
> > >
> > > When everyone feels they have made their arguments, create a poll
> > on
> > > the
> > > name.  Also, getting some informal approval of the final proposal
> > in
> > > the
> > > wider W3C community is an important part in my opinion.  I see
> > little
> > > that
> > > must be unique to Automotive in the fundamental parts of this.
> > 
> > Makes sense. I have no strong preference personally.
> > 
> > > > > [From Ted]
> > > > > Since there are cases that may have multiple VISS
> > implementations
> > > > > in the
> > > > > same network, or have client devices introduced, discovery is 
> > > > > needed.
> > >
> > > That's one driver, but not the only one.  For me it would be more 
> > > that it's the existing generic solution to discover a service if 
> > > it's
> > unknown
> > > where it
> > > is.   I wonder how realistically useful it is especially for
> > multiple
> > > servers.  In a particular car it seems kind of unlikely to me
> > that
> > > the
> > > applications will (or even should) know what to do, if a lookup 
> > > yields multiple VISS servers responding.  It opens up for a whole 
> > > bunch
> > of
> > > rules/policies that need to be there - which server do they
> > choose to
> > > communicate with?  Try one, if it fails, try the next?  It just
> > seems
> > > to be
> > > a whole other level of policy definition that this specification 
> > > should probably not venture into.  It seems more likely to me that 
> > > a particular application standard will provide a single (local) 
> > > source of
> > contact
> > > - if a
> > > more advanced system is needed, this could be funneled through a 
> > > server acting as a proxy even.
> > >
> > > The end result for me is that a particular system will often fall 
> > > back onto system-specific rules anyway (which means that 
> > > specification
> > could
> > > even
> > > include things like the name of the default server).
> > >
> > > > > I have the impression the TAG will block us if we do not
> > have it
> > > > > and
> > > > > will accept a reasonable fallback default name that will be 
> > > > > usable in the simpler cases (one VISS service on a fixed 
> > > > > network).
> > >
> > > In my opinion that may still be enough.  Beyond that it's 
> > > implementation dependent.
> > >
> > > > > Are their any suggestions how we can/should move forward?
> > > > > Ted/Rudi is
> > > > > their a statement or phrase or change that we could add that 
> > > > > achieve the objectives you've succinctly outlined?
> > > > >
> > > > > If we can't find a technical consensus, to move forward, can
> > we
> > > > > de-scope
> > > > > resolving the hostname and simply state that the implementer
> > will
> > > > > specify how to connect to the VISS server including how to 
> > > > > resolve the <host_name>?
> > > > >
> > > > > [Although not ideal - believe this isn't quite as big a
> > practical
> > > > > problem as first appears: OEMs are very concerned about
> > safety,
> > > > > cybersecurity and integrity of the platforms they are
> > creating.
> > > > > As a
> > > > > consequence, I believe that in practice client software that
> > is
> > > > > downloaded or included in the build for a particular OEMs 
> > > > > platform will need to be carefully QA'd to ensure it works 
> > > > > well on that platform, and is very likely to require some 
> > > > > configuration information
> > relating
> > > > > to the
> > > > > platform. So adding config info to specify how to connect to
> > a
> > > > > particular VIS Server or Discovery Service would typically be
> > in
> > > > > addition to other info. ]
> > >
> > > I partly agree.  I noted before that more than anything this is 
> > > likely part of some "application standard", which might be widely 
> > > adopted, or
> > OEM
> > > specific depending on what the industry wants.  (I have always
> > wanted
> > > to
> > > work toward the former, but the OEMs are not clear enough on
> > their
> > > desire
> > > there).  The scope of VISS specification isn't really an
> > "Automotive
> > > Web
> > > Application Standard".  That would be some different
> > specification it
> > > seems
> > > to me.
> > >
> > > That said, I could still see some value in W3C taking the first
> > step
> > > to
> > > define one single recommended FQDN for the default VISS server.
> > >
> > > > >
> > > > > Keen to hear the thoughts of the group re. how to move
> > forward...
> > >
> > > To move forward I propose:
> > >
> > > - Set a deadline for further arguments to be brought forward.
> > > - Then, list all the options for the spec.  See that we all agree
> > on
> > > the
> > > list.
> > > - Conduct a poll.
> > >
> > > I don't mean that guarantees a decision, but it's a clear
> > step.  If
> > > the poll
> > > shows good consensus, it's easy to go ahead.  If it doesn't,
> > perhaps
> > > simple-
> > > majority is not enough for a decision, but then I think a little
> > more
> > > discussion among those that disagree will eventually lead to a 
> > > compromise and consensus.
> > >
> > > - Gunnar
> > >
> > >
> > > > >
> > > > > Thanks and regards,
> > > > >
> > > > > Kev
> > >
> > >
> > > - Gunnar
> > >
> > > --
> > > Gunnar Andersson <gandersson@genivi.org> Development Lead GENIVI 
> > > Alliance
> > >
> > > > >
> > > > > Kevin Gavigan BSc, MSc, PhD, MCP, MCTS Software Architect 
> > > > > Connected Infotainment Electrical, Electronic and Software 
> > > > > Engineering (EESE) Jaguar Land Rover
> > > > >
> > > > > Mobile: 07990 084866
> > > > > Email: kgavigan@jaguarlandrover.com
> > > > >
> > > > > Office address:
> > > > > GO03/057 • Building 523, Gaydon • Maildrop: (G03) Jaguar Land 
> > > > > Rover • Banbury Road • Gaydon • Warwick • CV35
> > 0RR
> > > > >
> > > > > On 21 October 2017 at 00:35, Streif, Rudolf <rstreif@partner.
> > jagu
> > > > > arlandr
> > > > > over.com> wrote:
> > > > > > Thank you Kevin and Ted. I really would like to put this to 
> > > > > > rest now and move on.
> > > > > >
> > > > > > If I recall correctly we discussed a w3.org subdomain
> > before. I
> > > > > > am not
> > > > > > sure why it got discarded at the time. However, I am
> > strongly
> > > > > > in favor
> > > > > > of it.
> > > > > >
> > > > > > Let's move ahead with an Editors Draft with a w3.org 
> > > > > > subdomain/hostname.
> > > > > >
> > > > > > Thanks,
> > > > > > Rudi
> > > > > >
> > > > > > On Fri, Oct 20, 2017 at 11:36 AM, Ted Guild <ted@w3.org>
> > wrote:
> > > > > > > Part of the pushback on wwwivi even with .local is that
> > it
> > > > > > > amounts
> > > > > > > to
> > > > > > > name squatting. We do not own .local so cannot lay claim
> > to a
> > > > > > > name
> > > > > > > there.
> > > > > > >
> > > > > > > Mark Nottingham asked if we considered a w3.org hostname
> > as
> > > > > > > the
> > > > > > > fallback with discovery still being the preferred method.
> > > > > > > Typically
> > > > > > > I
> > > > > > > have authority on w3.org subdomains but since it is for a 
> > > > > > > specification, would need to get Director approval.
> > > > > > >
> > > > > > > https://github.com/w3c/automotive/issues/233

> > > > > > >
> > > > > > > Since there are cases that may have multiple VISS 
> > > > > > > implementations in the same network, or have client 
> > > > > > > devices introduced, discovery is needed. I have the 
> > > > > > > impression the TAG will block us if we
> > do
> > > > > > > not
> > > > > > > have
> > > > > > > it and will accept a reasonable fallback default name
> > that
> > > > > > > will be
> > > > > > > usable in the simpler cases (one VISS service on a fixed 
> > > > > > > network).
> > > > > > >
> > > > > > > Discovery makes things complicated for client
> > applications
> > > > > > > and may
> > > > > > > have
> > > > > > > other negative implications such as introducing ways to 
> > > > > > > attack the client. These would need to be worked through. 
> > > > > > > We could publish a snapshot of the Editors Draft as a 
> > > > > > > Working Draft with a w3.org hostname (pending approval) 
> > > > > > > while we figure out the discovery
> > issues.
> > > > > > >
> > > > > > > On Fri, 2017-10-20 at 11:15 +0100, Gavigan, Kevin wrote:
> > > > > > > > Hi Gents,
> > > > > > > >
> > > > > > > > As we know, issue #223 is the only open issue for the
> > VIS
> > > > > > > > Specification and it would be great if we could resolve
> > it
> > > > > > > > so that
> > > > > > > > the Chairs could propose the the specification moves 
> > > > > > > > forward to a Candidate Recommendation.
> > > > > > > >
> > > > > > > > I've added the text copied in blue below to the issue
> > (as
> > > > > > > > part of
> > > > > > > > trying to achieve consensus) and would be grateful for
> > your
> > > > > > >
> > > > > > > feedback.
> > > > > > > >
> > > > > > > > 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
> > > > > > >
> > > > > > > suggest a
> > > > > > > > default value for the VIS websocket 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
> > > > > > > > their
> > > > > > >
> > > > > > > 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 or
> > > > > > > > is not
> > > > > > > > preferred, a different value can be configured prior to 
> > > > > > > > deployment
> > > > > > >
> > > > > > > of
> > > > > > > > the client OR the client could make use of a Discovery 
> > > > > > > > Service if
> > > > > > >
> > > > > > > the
> > > > > > > > implementer has stated in their documentation that this 
> > > > > > > > will be available.
> > > > > > > >
> > > > > > > > I didn't want to tightly couple the spec. to a
> > particular
> > > > > > >
> > > > > > > Discovery
> > > > > > > > protocol or mechanism (as these could evolve separately 
> > > > > > > > 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...
> > > > > > > >
> > > > > > > > [Hopefully, we can settle on this (or something like
> > it)
> > > > > > > > for now,
> > > > > > >
> > > > > > > and
> > > > > > > > if there are strong views later about an alternative,
> > we
> > > > > > > > re-open
> > > > > > >
> > > > > > > the
> > > > > > > > issue at that point]
> > > > > > > >
> > > > > > > > Thanks and regards,
> > > > > > > >
> > > > > > > > Kev
> > > > > > > >
> > > > > > > > Kevin Gavigan BSc, MSc, PhD, MCP, MCTS Software 
> > > > > > > > Architect Connected Infotainment Electrical, Electronic 
> > > > > > > > and Software Engineering (EESE) Jaguar Land Rover
> > > > > > > >
> > > > > > > > Mobile: 07990 084866
> > > > > > > > Email: kgavigan@jaguarlandrover.com
> > > > > > > >
> > > > > > > > Office address:
> > > > > > > > GO03/057 • Building 523, Gaydon • Maildrop: (G03) Jaguar 
> > > > > > > > Land Rover • Banbury Road • Gaydon • Warwick •
> > CV35
> > > > > > > > 0RR
> > > > > > >
> > > > > > > --
> > > > > > > Ted Guild <ted@w3.org>
> > > > > > > W3C Systems Team
> > > > > > > http://www.w3.org

> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Rudolf J Streif
> > > > > > System Architect - Open Source Initiative Open Source 
> > > > > > Technology Centre
> > > > > >
> > > > > > M: +1.619.631.5383
> > > > > > Email:  rstreif@partner.jaguarlandrover.com
> > > > > >
> > > > > >
> > > > > >
> > > > > > UK: G/26/2 G02 Building 523, Engineering Centre, Gaydon, 
> > > > > > Warwick, CV35 ORR
> > > > > > US: 1419 NW 14th Ave, Portland, OR 97209 jaguar.com | 
> > > > > > landrover.com
> > > > > > -------------------
> > > > > > Business Details:
> > > > > > Jaguar Land Rover Limited
> > > > > > Registered Office: Abbey Road, Whitley, Coventry CV3 4LF 
> > > > > > Registered in England No: 1672070
> > > > > >
> > > > > > This e-mail and any attachments contain confidential 
> > > > > > information for a specific individual and purpose.  The 
> > > > > > information is
> > private
> > > > > > and
> > > > > > privileged and intended solely for the use of the
> > individual to
> > > > > > whom
> > > > > > it is addressed.  If you are not the intended recipient,
> > please
> > > > > > e-mail
> > > > > > us immediately.  We apologise for any inconvenience caused
> > but
> > > > > > you are
> > > > > > hereby notified that any disclosure, copying or
> > distribution or
> > > > > > the
> > > > > > taking of any action in reliance on the information
> > contained
> > > > > > herein
> > > > > > is strictly prohibited.
> > > > > >
> > > > > > This e-mail does not constitute an order for goods or
> > services
> > > > > > unless
> > > > > > accompanied by an official purchase order.
> > > > > >
> > > > > >
> > > > >
> > > > >
> > >
> > >
> > --
> > Ted Guild <ted@w3.org>
> > W3C Systems Team
> > http://www.w3.org

> > 
> 
> 
--
Ted Guild <ted@w3.org>
W3C Systems Team
http://www.w3.org

Received on Wednesday, 1 November 2017 19:11:13 UTC