afpayments / qcat_qr_ticketing_standard Goto Github PK

The expiry time is defined with the ticket creation time as a base, which makes it awkward to define an expiry period from the ticket effective time.

If an effective time is included in the ticket it is likely that the ticket creator would like to define a validity period from the effective time and from the creation time. Therefore the specification should be changed as follows:

8.2.1.4. Ticket Validity Period - "Time period in seconds from the time of ticket effective time if effective time is included in the ticket or from creation time if not. After the validity period is over the ticket is not valid anymore."

Tickets Valid for Multiple Operators

The specification should clarify how a ticket can be issued for acceptance at multiple operators.

The Problem

Let's assume we have a route R1 that is serviced by 3 operators O1, O2, and O3 that are associated in a consortium. The ticket issuer would like to issue a ticket that can be used from station A on any bus on this route R1 regardless which operator operates the specific bus the passenger is taking.

The operator IDs of the three operators are O1: 101, O2: 102 and O3: 103.

To achieve this, the ticket issuer could include all three operator IDs in the ticket. This is a valid solution only if all three operators use the same stop ID for the same stops. For example, if all three operators use stop ID 20 for station A, the ticket would contain operator IDs [101, 102, 103] and stop ID [20].

However, it is possible that the three operators service other routes and assigned ID 20 to another stop already and therefore each may assign a different stop ID to station A on route R1. Now the ticket would contain operator IDs [101, 102, 103] and stop IDs [1, 2, 3] and it is not possible to know which stop ID belongs to which operator (because the BER encoding of a TLV data structure does not gurantee the order of fields).

Solutions

Custom Validity Domain

The operators could ask the QCAT Registrar to combine the three operators into a custom validity domain D1, for example with ID 0x8001 and assign a new stop ID 1 to station A.

Assign Participant ID (aka Operator ID) to Operator Group

The operators could ask the QCAT Registrar to issue a new operator ID to the three operators, for example with ID 104 and assign a new stop ID 1 to station A, which is unique in combination with operator ID '104'.

Change of QCAT specification

The QCAT specification could be changed to allow pairs of operator id and stop ID.

Example for ticket with two operators and two boarding stops, which is ambiguous and currently not allowed

T: 63 (3/APPLICATION/Constructed: Application specific transparent template)
L: _ (_)

    T: C6 (6/PRIVATE/Simple: Transport Operator Id)
    L: 01 (1)
    V: 65 (101)
    ------
    T: C6 (6/PRIVATE/Simple: Transport Operator Id)
    L: 01 (1)
    V: 66 (102)
    ------
    T: CB (11/PRIVATE/Simple: Boarding Station)
    L: 01 (1)
    V: 01 (1)
    ------
    T: CB (11/PRIVATE/Simple: Boarding Station)
    L: 01 (1)
    V: 02 (2)
    ------

Example for a ticket with one single boarding stop that has a different ID for operator 101 and 102

T: 63 (3/APPLICATION/Constructed: Application specific transparent template)
L: _ (_)

    T: E1 (1/PRIVATE/Constructed: Unique Boarding Stop)
    L: 06 (6)
        T: C6 (6/PRIVATE/Simple: Transport Operator Id)
        L: 01 (1)
        V: 65 (101)
        ------
        T: CB (11/PRIVATE/Simple: Boarding Station)
        L: 01 (1)
        V: 01 (1)
    ------
    T: E1 (1/PRIVATE/Constructed: Unique Boarding Stop)
    L: 06 (6)
        T: C6 (6/PRIVATE/Simple: Transport Operator Id)
        L: 01 (1)
        V: 66 (102)
        ------
        T: CB (11/PRIVATE/Simple: Boarding Station)
        L: 01 (1)
        V: 02 (2)

This is to request an additional field to captures the payment tenders on the issuing.