meeting minutes 2021 - UnionInternationalCheminsdeFer/OSDM GitHub Wiki

• Sandbox V1.3 released including updates to the POSTMAN selection

• Requirements on an automated certification process

  • Certification can be done by two persons in one day.

  • Means to upload relevant information to certification group

    • information about credentials and URL
    • set of tests, including documentation
    • information on trains, products, fares, reduction cards, (seat map if needed)

  • Support different levels of certification

    • Mandatory, i.e. basic certification
    • Functional extensions to the basic set

  • The party wanting be certified should be able to run the process by its own prior to the submitting it to the offical certification process.

  • Provide a means to show the results of the test run.

  • Tooling support

    • Test driver on the API level. AIM: functional correctness
    • Simple shop implementation interface that allows to validate replies of a given reply. AIM: semantically correctness

  • Optional: Measure of response time.

  • Provided by OSDM tech group to solution provider

    • OSDM API
    • Test variations needed
    • Support

• Finalizing I-41
• Working on documentation

Discuss & address the encoding of names:

• [ICAO] (https://www.icao.int/publications/Documents/9303_p3_cons_en.pdf)

Split group

• Group 1: Documentation
• Group 2: Event Modelling

1. Small demo on events in S3

Lessons learned:

• Address security
• Add subscription mechanism

Decision:

• Update specification to OpenApi 3.1 to benefit from web hooks
• Model eventing (webhooks) in a different version

2. Synchronization

Covered

3. Finalize TCO change

PR merged

4. Quality of current API

Crunch42 API Security Audit shows issues to address

Finalize exchange states.

• for the (old) fulfillment there is no difference whether it has been refunded or exchanged: in both cases it is no longer valid
• therefore, adding a state "exchanged" to the fulfillment adds no value but complexity
• need to mention in the documentation that "refunded" also applies to the exchange process.

I-44 Booking Synchronisation Management

Message to distributor should contain

• booking id
• version of the booking (e.g. ETAG)
• list of event types
• need to define message format in JSON
• With the ETAG and the booking id the distributor can filter out changes they caused themselves
• for other changes, the distributor should retrieve the booking (or part thereof, depending on the event type)
• notification on complaints - separate stream, put into I-39
  • Message structure would be similar:
    • complaint id
    • version of the complaint (e.g. ETAG)
    • list of event types (currently only one: COMPLAINT_DECIDED

Technical message flow

• could use message queues or http/REST calls
  • http/REST has the advantage of not introducing new technology into OSDM: we will use a http/REST call
• recipient has to confirm the receipt, once they confirmed the responsibility to process is on the recipient
  • on 5xx-Error, sender will retry, on 4xx-Error or 20x-Success, not retries by sender
  • on retries, sender should use exponential back-off (increasing timeout values)
• callback URL should be configured into the technical configuration of the setup between provider and distributor
• semantic effect of events discussed - for details see I-44 and I-39
• Side issue: is the "booker" identical to the/a passenger? How do we know that?

I-45 Add responsible TCOs in the data from fare providers

• Allocators need to know the list of possible TCOs for a particular fulfillment so they can mark the Tickets sent to eTCD accordingly
• Information needs to come from fare providers (typically, TCO = carrier, but may be different in exceptional cases)
• Information needs to be handled by allocator in their backend, but does not need to be forwarded to distributors
• Model: Fare provider - allocator - any number of distributors
• Should the model be: Fare provider - allocator - another allocator - distributor --> the second allocator acts as a distributor. First allocator has the responsibility to interface with eTCD, so only they need the information about the TCOs
• has been modeled by Clemens, but is still in a separate branch

• FYI: Finalized v1.3 and forward ported v1.3 to v1.4-rc
• Add documentation reviews.
• Discuss improvement by Amadeus

Approved by work group, should be scheduled for v1.5.

• Organize lead for next Friday --> Ralf in charge.

Work on I-44, brain storming on event types.

• Modelling and its impact on code generation
  • Review and fix issues

Fix Inlines and remove warnings from GET resources

• Backward compatibility / Semantic versioning

• Review Clemens' work

I-35, I-41, I-42 and I-43 are designed

• Documentation to improve:

  • Search for Booking

  • Direct Booking

  • Master data resource

  • Claim Management

  • Non-Homogenous offers (Trenitalia case)

  • Asynchronous communication

  • Use of headers

  • Pagination

  • General review of documentation

    • Requirements, Business Capabilities, Models and Processes (Koffi, Nicolas, Andreas)

• Update the getting started (Andreas)

• Add search for bookings including pagination (Nicolas)

URN

• Adding stations, service brands/products, companies as name spaces

• Added tracing headers (optional)
• Overlapping codes cleaned
• Release of V 1.3
• Grooming of V 1.4
• Discussion on Master Data

Possibilities

• Synchronous Download (opt. with paging)
  • GET /masterdata/
• Asynchronous
  • Queue

Versioning is needed, time to life indicates frequency needed to update

Handling of delta is difficult -> complete data set preferred

Decision: Add masterdata to the existing YAML file.

Interesting master data

• OSDM offline package
• reductions (code + description, Online: CardReference, Offline:)
• stations (uic code, list of alternate names, coordinates, i18n, type, Online Place)
• (products)
• code lists

Master: provider

• /masterdata/reductions
• /masterdata/places
• (/masterdata/products)

Master: UIC (excel list)

• /masterdata/codes/cardType

• Presentation of I-44 by ETT

PI should by part of PI 1.4

• Clarification AccommodationSubType and PlaceProperty

Overlapping semantics -> Clemens does an overview of the concepts map

• Finalize part 1 of groups

Booker added to the OSDM specification

• Adding idempotency headers

Idempoteny headers to OSDM

Removed /bookings/search

• Feedback of PSS on Scope

Scope accepted

• Presentation of Billeto's test set.

Test set available on Github under /mocks

• Patch merged on coachLayout

  • https://github.com/UnionInternationalCheminsdeFer/OSDM/pull/228

• Getting reductions by a service.

Added as I-42

• Finalize groups

• Add idempotency headers (@Nicolas)
• Fix coachLayout semantics (@Clemens)
• Finalize groups

Discuss #227

• Decision: you can search an offer either by OfferSearchCriteria, a list of trips or a list of tripIds. In all cases you have to indicate which part of the trip should be priced. Both need to be passed in as a pair, e.g (trip, sub trip to price).

State of PI 3

• Todo update documentation
• Add vehicle filter (done)
• Define when two trips are identically from the point of view of offer search

Discuss scope of PI-4 to be presented at PSS and PES (26.-27.11.)

What's next

• remove version in links
• add title in links
• service arrival in timed leg intermediate stops cannot be mandatory (not specified when you cannot step out of the train

Review Enablers changes

• cf https://github.com/UnionInternationalCheminsdeFer/OSDM/pull/224

URNs code, code list => domain:codelist:code => URN:STTN:UIC:880001 => go for it

• update swagger
• update code list page & documentation
• can we allow default for both domain and code list so that only a code is actually needed and still call this a urn ? Would make it compatible with current data structure of the offline OSDM, which can be desirable at first. We could make this possible without "advertising" for it in the standard documentation

Idempotent post, patch and put

• We do not want it on offers.
• We may want it on post /booking (to be discussed cf re-usable offers etc).
• We probably want that on most "change" operations (post subresource, puts and patches) => is mostly documentation **** raises up the concurrency and last resource version discussions (cf etags and use of if-match if-none-exists etc) => todo nicolas

Make embeds a parameter in POST as well?

• No we decide to keep it where they are (at the moment there are never query parameters to our posts)

Add train number as a trip search criteria?

• agreement to add it, to be understood as "returns connections that contain that train number" (as opposed to connections that only contains that train number.
• check what OJP does about this
• could later evolve to a list of trains but this implies further discussions on interpretation (is it and, or, x-or ?)

How to add reduction cards to the code list

• Proposal: have a specific format in which the UIC and each provider's own list of codes would be specified. Each consumer can then build his own list based on the providers he is talking to (UIC+ the list of each provider) The format could be taken over from the OSDM offline format.

• OK as a principle, the question is how to spread the codes

• Since those are used in bi-lateral contexts, communicating applicable codes is up to the two parties

• A publishing mechanism should be proposed (=> git (with osdm offline format), or OSDM platform ?) => should be discussed with OSDM offline so this part of the dataset can be made public => Clemens.

A lot of trips elements are mandatory, so it is an issue when we do not want to embed trips. A solution would be that for each resource you have at the "root" id, links, and an optional "content" element with the actual information, where mandatory flags are set => todo (Nicolas)

=> with the evolution via other changes, this issue is now resolved

Identifying vehicles

Shouldn't vehicles have always either a number or a line ? proposal is to have a comment indicating one should always be specified comment Clemens: maybe we should wait for the transmodal alignement as this may be impacted.

• the publishedService name can be used for line information
• still need to change trainNumber into vehicleNumber (might be something else than a train)

• Finally finalize OJP
• Holiday ASC -> Nicolas leads the next two meetings.

• Work on OJP patch

• Demo of Biletto by Josef

First system to be live!

• Introduction of Koffi-Frederic Konan

Welcome on board!

• A Gentle Introduction to OSDM

Please review Gentle Introduction to OSDM

• Organize merge of OJP OSDM patch

Workshop next week.

• Work on I-30 Add the possibility for direct booking

Two aspects need to be taken into account:

1. Speedup for experts
2. Reduced look to book ratio

If offers are reusable a distributor needs to search for offers once, but then can cache these offers (equivalent passenger type (age category and reductions), same itinenary (same trains, same date), same product). The price can possibly change at booking time.

Especially if offers are not train bound / trip bound offers are reusable.

Todo: @Eliza adds a documentation and sequence diagram.

Special offers (e.g. "Bundeswehr", "Légion étrangère", "Vote in Italia") are modelled as promoCodes. Important: A allocator needs to check whether the requesting party is authorized to offer such special offers.

• Open Topics
  • How to process a request for reaccommodations in case of missed connection and through ticket?
  • Do we want to provide the ability to have in a same bookings non-related offers, i.e. offers for different set of passengers and/or independent journeys?

1. Small demo by SBB
2. Work on patches & questions
3. Finalizing support for promotions (I-29)

PromotionCode:

• Token that reduces the price at pre-booking time OR
• Token that reduces the price at shopping time OR
• Token to receivce offers that are not available without it.

Voucher: Token that reduces the price at payment time

1. Feedback

2. Discuss OJP review results

Roland & Nicolas:

• Make it less ambiguous
• Remove oneOf/allOf/anyOf - preferably by using
• Code list for station codes

3. Resolve remaining open points

4. Add support for promotions (I-29)

1. Short update on UIC's PES meeting

Scope was formally endorsed by PES

2. Initial landing of OJP patch

See: https://github.com/UnionInternationalCheminsdeFer/OSDM/tree/ojp-merge

Please report issue on Github.

1. Start using Kanban to address open issues

   • https://github.com/UnionInternationalCheminsdeFer/OSDM/projects/1

2. Resolve points emerging from the Hackathon of Amadeus & Sqills:

   • Lessons Learned by Implementing Parties

3. Work on I-4 and I-8

   • See Excel for comparison.

1. Review of final Scope of PI-3 + planning

All the improvements have scoped for PI-3 have been discussed and initially analyzed.

1. Presentation of Amadeus' Work

2. Landing work on /place-informations and /trips

3. Scoping PI-3

4. Paragraph on authentication, please review: https://unioninternationalcheminsdefer.github.io/OSDM/spec/technical-principles/

5. Overview: Language used by implementing parties.

1. Presentation of Bileto's use of OSDM

Welcome on board and congratulations for the soon to be live implementation.

2. Inconsistency in POST trip-offers-collection and POST non-trip-offers-collection

Fix inconsistency

3. Q&A with OJP expert (Stefan de Konik).

4. Multiple Segments

Describe two possibilities

1. Merging legs of trips but offer two offers.
2. Returning two trips

5. Authentication Process

Conclusion: JWT token short lived and digitally signed (in production: <10 min) Don't reinvent in the wheel (OAuth2 compliance). Link to WASP API standard

1. Authentication process feedback

See OSDM authentication mechanism

Discussion postponed as Nicolas and Roland were locked out.

2. Update on OJP4OSDM

See Online OJP documentation.

Major difference: A Segment is called TripLeg which is abstract. Concrete implementations then are:

• TimedLeg: passenger TRIP LEG with timetabled schedule
• TransferLeg: A leg which links other leg of a trip where a transfers between different locations is required
• ContinousLeg: A leg of a journey that is not bound to a timetable

Andreas provides a patch.

3. Short presentation on OSDM in EA-Sparx. This modelling was done as a prerequisite for the OSDM alignment with Transmodel.

As part of the modelling a small inconsistency was discovered (NonTripOffer vs Offer).

Thus Offer will be replaced with TripBasedOffer and NonTripOffer with NonTripBasedOffer.

Andreas provides a patch.

4. Add train number as a trip search criteria.

The need comes from the H2O converter. In H/H, a BookingRequest consists of date, and trainNumber.

The semantic for are single leg is clear: Only return trips where a vehicle with the given trainNumber (better vehicleNumber) is present. For a multi leg (segment) trip, the semantic is less obvious. Possible interpretation: only return trips where one of the legs is run by a vehicle with the vehicleNumber.

Home Work: Check whether your trip planning software supports such a semantic.

5. Multiple Train Numbers per Segment

Several solutions have been discussed, see below.

Home Work: Check whether you have a preference for any of the solutions.

6. Scope of PI-3

Proposal:

• For PI-3 concentrate supporting implementations with mocks/documentations/reviews and only add new features with high business need.

Home Work: Check with your teams what features are really needed.

1. How to add reduction cards to the code list - OSDM Offline code list format (C.Gantert)

Clemens presented the structure used in the offline model For generic cards, there is no need to specify an issuer

• For specific cards, their specificities would be exposed using the Offline format. The code to use in the API > is the id of the offline reduction card format, and starts with the issuer's RICS code
• We decide to not consider the case where a specific card number is required to get a price, as it would > complexify the grammar too much.
• An additional warning message could be foreseen to indicate a given card was not taken into account. => code change !
• The international disabled reduction cards needs to be added in the UIC list, and when it is done we add it in our list. ** Clemens will add it.

• File a new improvement for centralized source for codelists. for ex: predefined format in a csv file on gitHub or other (offline platform is an option as well, of sFTP, or ...) => Nicolas

2. Vehicle (continued)

   Shouldn't vehicles have always either a number or a line ? proposal is to have a comment indicating one should always be specified

   Comment Clemens: maybe we should wait for the transmodel alignment as this may be impacted.

   Our discussion is whether we should support line numbers => We should support both at least in the responses, at least one must always be provided.

1.Proposal to improve authentication (Nicolas)

Nicolas to share schemas and documentation reference with the group All parties check the provided material with respective security experts and come back to the group with conclusions

The agreement is that whichever way it goes, it does not impact the API specifications of the transactional messages. Specific questions are

• Can we live with JWT that are not digitally signed by the client (and survive a security audit)?
• Do we need the token factory on bob side as part of the standard, or can it be left to implementer / assigned to consumer (self-issued token mechanism cf open id connect)

=> homework to be checked by 2021-06-04

2.Finalize support for partial refund/exchange (I-3)

• From an API operations standpoint, the most atomic element we can aftersale on is a ticket/TCN. Rationale
• going lower makes the logic really complex
• this is what is currently supported by web-oriented systems (some expert systems support manual processes to cover more granular operations) Consequences Refunding 1 pax on a multipax collective ticket is considered an exchange => the current API specs are covering this case (to be confirmed) some edge cases may cause an issue
• if the train is sold out it will not be possible to refund one pax out a multipax ticket
• the seats or price ranges of the original booking may not be available anymore

Note that supporting individual ticketing only certainly simplifies the case, but would seriously impact adoption of OSDM. Proposal : when just changing passengers set, only provide the passengers element in the ExchangeTripOfferRequest. (still supported by the syntax). Note this may still imply complex logic for the provider (ex: check if tariff conditions are still valid, whether seating options are still ok ex: wheelchair). Or the provider can implicitly refetch the original requests if they do not wish to support the party size change explicitly. => to be added in documentation => I-3 is hence closed.

3.Review home work

No additional feedback

4.How to add reduction cards to the code list

Proposal: have a specific format in which the UIC and each provider's own list of codes would be specififed. Each consumer can then build his own list based on the providers he is talking to (UIC+ the list of each provider) The format could be taken over from the OSDM offline format.

5.Passenger structure

• Why do we have abstract & links as mandatory ? since we use it in requests as well, it does not make much sense (links in passengers for offer requests => ??)
• we should add a list of passengers in the offer (and add it in the embed list). From an implementation standpoint. passengers in commonOfferPart then in reality are populated only with ids and links => todo (Nicolas)

6.Trips a lot of trips elements are mandatory, so it is an issue when we do not want to embed trips. A solution would be that for each resource you have at the "root" id, links, and an optional "content" element with the actual information, where mandatory flags are set => todo (Nicolas)

7.Code generation

Proposal is to encapsulate all inlined responses into response objects as otherwise code generation produces unnamed objects. => todo (Nicolas)

8.Vehicle

Shouldn't vehicles have always either a number or a line ? proposal is to have a comment indicating one should always be specified comment Clemens: maybe we should wait for the transmodal alignement as this may be impacted.

1.Reservation System Code in MERITS to find reservation system

• Information on where to book the seat information can be part of the MERITs exchange format. More precise, it's the carrier.
• Unfortunately it's not used by all providers of time table information.
• Conclusion: Interesting information, should be made consistently available --> Talk to Merits expert (Fabrice)

2.Complete support for partial refund/exchange (I-3) based on the document by EU TravelTech

• Definition: Upselling is an operation at booking time, exchanging which can include upgrading/downgrading is an operation at after sale date.
• Re-Accommodation is interesting, however not in scope for the upcoming OSDM version 1.2. The idea is that the allocating system informs the distributor systems about events, e.g. disruption. Technically this could be done using webhooks for example (webhooks are part of OpenAPI 3.1) --> Add improvement for error and re-accommodation management.
• Partial aftersale is the modification (refund or exchange) of a subset of the passengers and/or a subset of the segments of the booking. We discussed what should be the atomic entry point for exchange or refund: fulfillment (that has a 1:1 relation with TCN) vs pax/segment/item (item could even be an ancillary). We have not yet concluded whether it's acceptable to propose that: a) when all passengers and segments covered by a fulfillment have to be cancelled a refund can be triggered on the fulfillment b) when a reduction of the number in party or a change of the itinerary, then an exchange can be triggered on the fulfillment. If the proposal is acceptable, then the fulfillment can be the atomic entity for aftersale and it would be aligned with current grammar definition. If not, then the grammar would need update in order to define the type of aftersale allowed on a fullfillment.

3.Presentation of the OSDM Offline Platform by Hitrail

The platform will be ready for testing end of May.

1. Recap meeting with OJP
   • What is our strategy?
   • Impact on current modelling?
   • How could an OSDM profile for OJP look like?

• OJP light is a way forward, using its semantics makes sense.
• OJP needs to be converted to JSON, work is ongoing at SBB.
• In case of conflict we go with Transmodel (!)
• Real time information as well as free floating legs are added value
• Conclusions: "OJP on diet" and "Swimming in the stream" is the way forward
• Clarify relationship between Hafas JSON and OJP
• ASC will provide a patch and look into the OSDM profile thing

2. Review Sqills token access point service

• Service is ready, will be added to GitHub including a refresh endpoint asap
• Sqills token will expire after 30 minutes

3. State of mocking
   • State of work by öBB

• Sets up a prototype to provide offer request.
• 1. Number of trip collections to be returned: add attribute "number of response" to TripSearchCriteria and default it to 5.
• 2. Parallel trains are already modeled as a list of numbers.
• 3. Add segment of type walk using OJP style (Ralf, Klaus, Andreas and Peter).
• 4. Clarify semantics of REAL_BOARDING_ALIGHTING --> OJP ("non commercial stops").
• 5. Merits code list: Clemens add the Merits numbers.
• 6. Add "bikeTransportNeeded" to TripSearchCriteria --> OJP
• 7. Add additional information on vehicle ("facility code" of Merits) as options.

• Review home work

• Do home work

4. Providing information where to shop to distributors

Quentin and Elisa reason about requirements

1. Non functional requirements

Looping scenario is not responded. Rename "average" to "95% threshold". Find responsible numbers. Open: Whether these requirements are optional or mandatory

2. Mock

öBB: creates an offer prototype, add EVA to codelist as "x-etensible-enum"

3. Semantic of fareResourceLocation

Scenario: Paris - London by Eurostar and API at api.sqills.com.

Fare Level

Lookup Allocator to Fare Provider

carrierLocations:
  - carrier: Eurostar
  - serviceBrandCode: Eurostar

trainLocations:
  - carrier: Eurostar
  - traindId: 293

stationLocations:
  - Paris: Sqills
  - London: Sqills

onlineResource:
  - offerType: TripOffer | NonTripOffer
  - interfaceType: OSDM
  - version: V1.2
  - system: Sqills

Allocator to other allocator - Open question

Offer Level

Distributor to allocator - Open question

4. Design token factory endpoint

Home Work: Fill out Nicolas' mock Excel ("Scenario Variations").

Update:

• Authentication is setup, review of service endpoint is next
• Sandbox is ready
• Document is ready and will be available soon

1. Fix needed in the offline schema. There is no impact on the online schema

2. Mock-up grid.

   Homework: everyone to look at the grid and place an X in own column to indicate willingness to represen t the variation in the scenario.

3. Mock-up infrastructure

   Assumption is we can all address the already existing mocklab OSDM endpoint. If so, how can we collaborate in the same mocklab project ?

4. Access to sqills endpoint ?

   Should be ready in about 3 weeks. At this point the endpoint will be shared. One point to address is how to set the authorization/ authentication part. for the rest, we do not go further than mentioning we follow OAuth2 proposal from Sqills: offer a fixed endpoint for the "token factory", part of the OSDM standard. This could act as a proxy that redirects to the provider's actual token factory. Standardize the way to get the token, not its content (such as validity period) Point for an upcoming agenda: design of the standardized enpoint.

5. Yaml improvement

   Try to follow more RFC-standards Prev Next standard links urn for enumarated values Nicolas to write proper improvements or it so it can be assessed and prioritized

6. I-18 review

   EP: we may need more than one tag in the booking request in case a provider proposes several segments with different through-ticket agreements This logic/situation needs to be toroughly documented

Question from Quentin: should we make post tikcet idempotent ? Nicolas: do we want to have idempotent POST ? At first sight No... but to be discussed further

1. Finally finalize I-18
2. Continue to discuss on Mocks 2a. Conceptual ideas (by Nicolas) 2b. Presentation of Sqill's approach 2c. Short presentation of MockLab

(1): Patch has landed

(2a):

(2b): Access to all members of the group, Sqills will add a new service for authentication. Breaking changes are still possible. Best-effort at most for up-time. Information on trips, trains et al. will be presented to the group.

(2c):

1. Short update of OSDM Executive Meeting
2. Review home work
3. Finalize I-18
4. Initial discussion on mocks with a
   • Presentation of live mock (by Roland)

(1): We need some tooling support to automatically test all the scenarios

(2): Discussion

• We have to define what the number means (max time, 95% of time)
• Find a balance between what is challenging and what is achievable
• Add non-functional requirements for distributors
• Will be part of version 1.2

(3): New encoding needed to tag to express reimboursement of offers.

(4): Highly interesting, big respect to the Sqill's team!

1. Finalize I-7
2. Start work on I-18
3. Feedback on mock scenarios

• Home Work: Review https://unioninternationalcheminsdefer.github.io/OSDM/spec/nonFunctionalRequirements/

1. Short update on OSDM meeting, especially the mocking topic
2. Short review of compliance section
3. Finalize I-16
4. Work on I-28

(1): Nicolas:

• Shift to work on assets, that help to implement. For example, work on mocks.
• Define and vary scenarios

(2): Decision: /trips and /products are mandatory

(3): Modelling is done, just needs some documentation

(4): Needs numericAvailability to be added to the offer and documentation

• Improvement needed on reservations and fares resources.
• Home Work: Think on scenarios.

1. I-16 Add support to sell non-journey based products (passes) => Review changes Changes applied are exactly those discussed last week + a few naming changes for clarity

• Still need to add the new fulfillment types in the appropriate code lists (if any)
• Still need to update the card types list in the appropriate code lists (if any)

2. I-28 Add support to query availabilities

• Maintain segregation between layout info and availability information
• We discussed whether querying availability information would be more relevant to do based on "inventory class", but in the end fall back to the current model, where availability calls are functions on offerparts within the offer
• These calls are indirectly per segment ODs (via the offer and reservation id)

3. I-7 Add full support for PRMs

• Requirements introduced by David S.
• We see three levels
  • Being able to file the request to ABT
  • Being able to handle unhappy flow
  • Investigate possibilities for pro-active information on chances of success of the booking
• Next session David & Clemens will make a more detailed presentation on the business flow
• Access to leaflet documentation to be checked for the work group members

1. Update:

   • V1.1 is tagged and released
   • For I-18 and I-7 we have clarified the requirements.

2. Finalize design of I-16

3. Start design of I-28

4. Homework: Please review: https://unioninternationalcheminsdefer.github.io/OSDM/spec/compliance/

(2):

• Define NonTripOfferSearch criteria:

  • Add freetext
  • Identify students by generic student card, similarly a generic card for military personnel, ...
  • remove isReservation, serviceClassIds

• Improve NonTripoffer

  • Add PassChip and PassReference to availableFulfillmentTypes

• Transform CardReference.type to an array, x-extensible value and CHIP-CARD

• Add optional address to PassengerDetail

• Rename street_nr to street

• Improve RefundOfferRequest:

  • add refundDate with default now. Date in the future is valid for partial refund of passes only.

• Decision: No support exchange operations on passes

(3) Split availabilities of fares and availabilities of places

• Limit availabilities to one day.
• Improve OfferSearchCriteria:

1. Release V1.1, final review

   • Review by öBB (ok)
   • OfferPart (ok)
   • feeAmount(ok)
   • boolean: true, false or undefined? (ok)

2. Design I-16:

   • I-16 Add support to sell non-journey based products (passes) (DB/öBB/SBB)

(1): Needs some alignement

• nearby-Request: "coach" and "place" shoud be mandatory? (ok)
• in the booking request "placeSelections[]/placeSelection{}/referencePlace{} and placeSelections[]/placeSelection{}/selectedCoach{}/..." the attributes should also be named "coach" and "place" as in the corresponding "nearby" Request (ok)
• do we also need a test booking request for particularPlaces?
• in the swagger the text at the attribute preferences and preferencesBundle (place-map, nearby, available-preferences) should be changed from "Place preferences (see code list PLacePreferences) the customer wants to have" to "Place preferences (see code list ReservationPreferences) the customer wants to have"

1. Overview of scope of PI-2
2. Add joint error codes by Klaus.
3. Introduction to the following PIs:
   • I-19 Add support for distributed tracing (SBB)
   • I-4 Align /locations and /trips to transmodel (OJP) (SBB)

(2): Add 409 on all POST/PUT/PATCH operations

1. Fix seat reservation, so that Version 1.1 has the same functionality than Version 1.0. Merge patch by Clemens
2. Merge I-1 patch by Eliza.
3. Add Relationship-Offer-Offerpart-Product-and-Fare to the standard.
4. Homework: Review updates on exchange documentation.

• (1): Turn POST operations into GET operations by splitting into three operations /available-preferences, /seat-map and /nearby.
• (1): ==> Rework needed, but feature is in for V1.1. Thanks Clemens!
• (2): Remove offerClusters as it is redundant to coveredSegmentIndexes.
• (2): A combinationTag on offer does not provide additional value --> not added. Combination of offers is controlled on product level.
• (2): Rework of /trip-offer-collection
• (2): Remodel tripId to tripHash (remove uuid type)
• (2): Collection of segments in trip search
• (2): New Boolean flag afterSaleByDistributorsOnly on BookingRequest.selectedOffers.selectedOfferIds structure
• (2): Combination criteria needs to be respected in after-sale processes (basically partial-refund on one part leads to exchange of the other part).
• (2): ==> Rework needed, but feature is in for V1.1. Thanks Eliza!

1. Finalize I-2 Support for stateless offers booking processes

   • Patch by Nicolas merged, thank you Nicolas!
   • Documentation updated

2. Discuss I-1-Enable-combination-rules-between-offers

• (1): Merge landed, however some seat reservation is broken
• (1): Joint view on seat reservation to be planned PI-3
• (2): Tag concept is valuable and thus should be added
• (2): Offers until the virtual border point between different allocators: possible to express on the API level.

1. Add requiredInformation grammar as part of the standard.
2. Discuss: I-2 Support for stateless offers booking processes
3. Change cardinality OfferPart to Product to 1..n or even 1..2. --> Document reason why 0..2 is necessary (included reservation or ancillary do not have a product).
4. Homework: Review Relationship-Offer-Offerpart-Product-and-Fare

• (1): add ANY keyword to express "any customer"
• (2): remove small grained resources
• (4): included reservations do not need a product

• (1): Grammar accepted for V1.1
• (2): Add an improvement for direct booking

1. Review updates on exchange documentation
2. Homework: Review: I-2 Support for stateless offers booking processes
3. Homework: Review requiredInformation grammar: https://unioninternationalcheminsdefer.github.io/OSDM/spec/requested-information-grammar.rrd.html

• Exchange patch will be reworked and discussed

1. Confluence moved to GitHub Wiki.

   Please sent me your GitHub accounts if you want to edit content.

2. Discuss and merge two improvements:

   • I-5-Add-support-for-a-fee
   • I-9-Add-binary-in-fulfillment-messages

3. Discuss and merge other pull requests.

4. Discuss adding Errors and Warnings as part of the standard.

• I-5, I-9, I-23, I-24 and I-25 have been approved and merged.
• Adding Errors & Warnings is generally supported by members. https://github.com/UnionInternationalCheminsdeFer/OSDM/blob/gh-pages/spec/errors-warnings.md