https://github.com/w3c/automotive/issues
PatrickL: [summarizes issue 299]
Ulf: we do have a section on
chapter metadata, to have authorization here is a bit
confusing
... we do have a header type to prompt for authorization. i
think within methods section there should be a description of
this message
https://github.com/w3c/automotive/pull/299
PatrickL: coming from HTTP, I
typically compare to it first
... there I need to check authentication for each method
request
... the communication in itself must have all the descriptions
necessary, having to do sequential requests breaks the RESTful
nature of HTTP
Ulf: in HTTP it does follow well
but from the web socket view it doesn't fit so well
... we can perhaps figure out a compromise
... I do not have a good proposal offhand but will give it some
further thought given your view
... there are also cases where there would be unrestricted
requests
PatrickL: I tried to give thoughts for web sockets cf VISS, HTTP and MQTT
Laurent: in HTTP you can think of
authentication more as metadata
... are we trying to create an auth mechanism across
protocols
... or we can stay protocol dependent
PatrickL: Laurent wanted to know what the requirements are server side
Laurent: I see several MUST and SHOULD on client side but not on server side
PatrickL: a service may not need authorization
Laurent: as a client vendor when
I see MAY I don't implement the feature
... we should have something there for basis of discussion and
see where we want to go
Ulf: I think if a service requires access restriction, the only mechanism should be the token we describe here
PatrickL: I will write that into
the description, thoughts on how to phrase?
... "if the execution of a method on a service needs
authorization, the service MUST use the authorization key/value
pair"
... regarding schema compliant, that is not defined
Laurent nods
PatrickL: all ok with the pull request associated with issue 299?
Ulf & Laurent: ok with me
https://github.com/w3c/automotive/pull/295
PatrickL: yes, I abandoned wildcard usage but left it in examples as I wanted to see how people feel about removing them from path level filtering
Ulf: we need to be consistent for
sake of those not in the group
... I would be ok with removing wildcard functionality provided
we can handle same things with query capability
... there is a discussion on VSS about modifying it to be able
to be able to handle more types of searches
... we should perhaps wait for VSS to mature before
representing it here
Laurent: I take word path as the literal path in URI
Ulf: technically you can with %encoding...
Laurent: yeah but is that standardized in W3C?
Ulf: no but legit with respect to URL RFC and characters
Laurent: XPath model with filter makes sense
Ulf: fine with removing wildcards in URL provided we have adequate search capability
Laurent: we may want to select a node or group of them based on location in the tree
PatrickL: we set off to find a solution incorportating VSS and ViWi. starting from VSS side makes sense
Ulf: I think we have attention of
the VSS crowd with Rudi previously and now Daniel and
Benjamin
... they are receptive to our ideas
... we wouldn't want to fork their model for our needs but try
to stay in line
Laurent: I would like us to be
independent so we can stand on our own in case there is later
deviation
... we do not want to be bound to subsequent changes in
VSS
... having one source of truth based on previous experiences
makes sense to me
Ulf: for me that would be
VSS
... I would rather start the discussion then about this group
owning that specification given the dependency
Magnus: I am not so keen on
branching off on our own data model either
... I have seen attempts to standardize on data models
before
... VSS has more attention than others I've seen which speaks
for keeping VSS but do note Laurent's concerns are valid about
the dependence
... if we start to deviate, then it might prompt others to as
well in choosing different data models underneath
Laurent: if we need something
strongly in VSS we need to put in lobbying effort
elsewhere
... we can fork it and see if they follow our lead instead of
us chasing them
PatrickL: what we put into our charter and working on is common pattern for in-vehicle services
<PatrickLue> https://github.com/w3c/automotive/blob/gh-pages/charter-2018.html
PatrickL: I hope others share that common understanding
Ulf: yes but we have influenced
VSS as well which we are dependent on
... it is possible to interpret the charter in slightly
different ways
Magnus: I think it was Adam who
wrote in VISS that VSS 1 was to be used as a model
... it worked based on how the request methods look
... as we add REST requests we have new challenges
Ted: I am always torn on how much effort to put into solving potential future problems versus avoiding them. given attention on VSS and VSSo dependence on it, overlap of GENIVI VSS and W3C people I think we should not consider forking until an irreconcilable issue arises. for VISS we agreed to snapshot a version and should for gen2 too
PatrickL: if they ever officially disagree we will try to work with that
Ulf: if we have a strong view and
unable to influence them then we end up in a situation where we
would consider forking
... I would prefer we go together with them
PatrickL: following that logic, would it be ok to accept this pull request and revisit as more is known about wildcard handling based on VSS evolution?
Ulf: I have further questions on this pull request and ask time to review
PatrickL: ok, please put comments
in-line and we will look at it
... that impacts our ability to discuss 298
https://github.com/w3c/automotive/pull/298
PatrickL: I modified my language
based on Gunnar's comment
... I started with a simplification of the data model, reducing
types from 6 to 2
... branches and values
... addressing we already had. I reduced the number of value
data types
... of course I am aware a real implementation has to be behind
it
... start with default restrictions on numbers, you need to
know what to expect for memory etc
... strings similarly have to be restricted as well
... .the third thing I introduced is type for a branch to set
expectation for structure
... I wanted to allow for additional branch types eg media. I
added remote branch idea which can point to a different
service
... this is an overview to help for your review
Ulf: I appreciate the work and see the merits but want to stay with VSS
Ted: I do like the remote branch concept
Ulf: we have the basic capability already in VSS
PatrickL: yes, I wanted to apply
schema for how a branch can look like
... schema can describe how to get to a remote branch
... it was influenced by your (Ulf's) previous
presentation
... I wanted to bring together the basic ideas of VISS and RSI
without alot of adaptation
Ulf: if that is not possible with current state of VSS we should point that out clearly and seek modifications in VSS instead of having our own view
Laurent: I wanted to fact check if VSS can do this and discuss differences on capabilities
Ulf: pointing out the differences would be a good start to see what is missing in one or the other
PatrickL: I will prepare
something for next week to make clearer the differences with
VSS
... please review this PR and issue. we will do a comparison
next week
[adjourned]