Minutes interim-2019-core-11: Wed 15:00
minutes-interim-2019-core-11-201908211500-00

CoRE WG Interim 2019-08-21 1500Z-1630Z

Attendees:
    Carsten Bormann
    Christian Amsüss
    Francesca Palombini
    Jim Schaad
    Klaus Hartke
    Michael Koster
    Peter van der Stok
    Thomas Fossati

Agenda:

1450Z..1500Z:
(Pre-meeting: Can you hear me now, 2019 edition)

1500Z..1510Z:
Agenda bashing
Document status (here: multipart-ct, senml-etch)
TF: make more explicit how context influences semantics
Other SDOs (here: senml-more-units)

1510Z..1540Z:
(Jim) Pubsub: Jim’s questions, i.e.:
1 — basic vocabulary -- sufficient to get started?
https://github.com/core-wg/pubsub/blob/master/proposal.txt
Klaus: anything should default to some value
content-format: default to first publish
expiry timer (on topic, on data): data expiry puts in tombstone, topic expiry
removes topic. Defaults? Finite data lifetime requires a tombstone, or it will
kill everyone's subscription. Topic lifetime may have a default that depends on
the server (eg. server is not willing to support unused topics for years), data
lifetime would default to infinite (server doesn't inerfere with the
publisher's wishes), but implicitly capped to the topic lifetime. — create on
publish — is that dead now? Klaus: in the current proposal, yes — significance
of order of elements (~ CoRAL/JSON discussion) current wire formats do allow
document order example with alternating authorizations and servers; use order
to "keep things together"? application can publish information into the pubsub
server that the pubsub server does not understand. cabo: This makes it hard to
introduce new server semantics, because an old server might let an application
publish info that now has server semantics Jim: pubsub prefix? (initial part of
a URI would be reserved to server semantics) Klaus: authorization semantics?
Christian: Server should state what is in its own authority, vs. statements by
someone else [provenance] cabo: using order to express grouping is dangerous;
order might be accidental; becomes a minefield then; Klaus: +1 — hierarchy
Klaus: good practice for servers to define the URLs; but hierarchy could have
semantics (e.g., inheritance) Jim: observing (resource) hierarchies? Michael:
good common collection patterns [might have observe semantics]; we never
standardized these; but it is likely we want this semantics Jim: can build
hierarchy in CoRAL; vs. in URL Michael: could also use FETCH to select things
Klaus: What does it mean when we have set up the hierarchy? Michael:
inheritance; subscribe to hierarchy Klaus: How does (the latter) work exactly?
— back path from data item to topic item? Christian: Montreal discussion -> we
can't do that (supporting any media type as a topic data) — initial publication
— how?  (e.g., multipart) Klaus: If tombstone creation is done, then initial
publication can be from the tombstone Next step: update draft-ietf-core-pubsub
with the updated proposal.  Add initial vocabulary to that (probably October).
Jim: Harvest to start ~ Sep 23, sparse in October...

1540Z..1630Z:
(Klaus) CoRAL, specifically CoRAL-JSON
Please see https://github.com/core-wg/coral/issues/17
Michael, Christian, Jim, Klaus acted as a design team for a CoRAL-JSON
serialization Design choices to be made.

(1) Move things into maps; Keep order?
(Can keep order within a link relation type, but not between link relation
types) Example: Give different links with different link relation types, use
order to express preference cabo: Introduce an array if ordering is actually
intended... { "a": ...
  "_ordered": [
        { "p": { "_link": "/a/1", "_ordered": [ ... ] } },
        { "q": [{ "_link": "/a/2" }, {"_link": "/q/4"}],
        { "p": { "_link": "/a/3", "_ordered": [ ... ] } },
        { "p": "/a/1" }
    ],
    "b" ...
}
can do grouping by indirection through null nodes: { "a": [ { "a1": foo, "a2":
bar}, {"a1": foo2, "a2": bar2}]}

(4) literals
cabo: Schema-informed requires consensus about the schema in all elements of a
processing pipeline cabo: Please use base64url (Section 5 of RFC 4648) with no
padding.

(6) CURIES
cabo: can this be done in a "deterministic" way, reducing the number of
alternatives that need to be visited? cabo: can an implementation pre-process a
curie list to pre-generate all aliases before searching them in the maps? cabo:
how to compose?  firewall or inheritance? cabo: please use different character
(not in URI prefix set), e.g., | Jim: "simple profile", no CURIEs, ... simple
to process, not look as pretty? (cf. SenML resolved records -- resolved CoRAL
without CURIEs left) Tues 6pm Stockhom for call == Next CoRAL DT meeting slot:
Tue 1600Z

1630Z..1730Z:
AOB Hallway meeting

Next Interims:
2019-09-04: Vacations; right before RIOT Summit.  Cancel.
2019-09-18: Klaus and Carsten still on vacation.
Slot might become an ACE meeting (possibly authors/design teams).