Page Comparison

Message structure

Jeremy

Jeremy > presents the slides related the message structure:

1. country code

• WIGOS uses 3-digit numeric ISO country codes; this was for encoding reasons (in BUFR?)

• WIGOS users find use of numeric country codes problematic

recommend WIS2 adopts 3-digit alpha-numeric country codes; easier to understand in mass market [agreed]

2. data policy?

• use of "core" and "recommended" in the topic tree

• allows for use of WMO Res 1 vocabulary for categorizing data

• recognize that this may introduce the need for additional transitions to manage movement of data from "recommended" to "core"

• there is also Canadian experience where users perceived a mix of open and restricted data in their message feed as problematic

• Canadian practice is to use separate channels for open and restricted data; the ground-rules for data access is set at the channel level

• alternative vocab for "core" and "recommended"? how about "public" and "restricted"?

• lots of discussion about the "core" and "recommended" terms in SG-DIP; also - they're approved by Cg; best to keep consistent terminology

• can we move {data-policy} up the hierarchy?

• no - the domain sub-categories (level 9) differ between core and recommended data-policy; "recommended" data sub-categories are (by design) much less defined

• mixing open and restricted data in the same message feed?

• for example, the following subscriptions would provide a mix of open and restricted data to a subscriber:

• wis2/CAN/*/data/*/weather/*

• wis2/CAN/+/data/+/weather/#

• this concern is all about access control; given our drive to separate concerns, we shouldn't mix data policy with access control; we should use a specific mechanism to deal with access control issues

suggest:

1. we could use channels to distinguish between open and restricted data; e.g. [ open | restricted | cache | … ]

2. provide guidance for client applications about how to manage HTTP 400 response codes (e.g. HTTP 401 Unauthorized) where they need to authenticate

but - we don't know if we'll need these mitigations yet, so let's try out the current proposal in the pre-operational phase now is the time to build some prototypes!

the message structure and topic structure are sufficiently agreed for us to continue [agreed]

Outstanding discussions

1. What gets added to the Global Cache

2. Defining the domain subcategories (topic structure level 9)

• need to start with a strawman proposal and ask domain experts for their endorsement

• make things simple; e.g. only use hyphenated phrases (no "+" or "4") such as "global-analysis-prediction"

• WMO No 386 Manual on GTS may provide some re-usable vocabulary in how TTAAii are described

• albeit that it's very fine-grained and we want to avoid coupling WIS2 to GTS concepts like TTAAii!

ACTION (Jeremy, Enrico): develop a first draft of level 9 sub-categories for Core data

1. Feasibility and design of GTS-to-WIS2 and WIS2-to-GTS gateways >> prioritize this for next week

2. Supplementary Global Services; e.g. "Replay Service"

3. And other decisions/recommendations/pending discussions circa 1-April-2022