Versions Compared

Version Old Version 1 New Version Current
Changes made by

Rafal Artych

Rafal Artych

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

The changes in Commonalities between rc-1 and public release:

For APIs using subscriptionevent subscriptions:

Added note and changed descriptions for date-time formats #404

Change the descriptions of subscription parameters:

SinkCredential

accessTokenExpiresUtc

startsAt

expiresAt

SinkCredential

Code Block
description: |            The type of the credential.             Note: Type of the credential - MUST be set to ACCESSTOKEN for now

AccessTokenCredential: accessTokenExpiresUtc

Code Block
description: |
                REQUIRED. An absolute (UTC) timestamp at which the token shall be considered expired.
                In the case of an ACCESS_TOKEN_EXPIRED termination reason, implementation should notify the client before the expiration date.
                If the access token is a JWT and registered "exp" (Expiration Time) claim is present, the two expiry times should match.
                It must follow [RFC 3339](https://datatracker.ietf.org/doc/html/rfc3339#section-5.6) and must have time zone. 
                Recommended format is yyyy-MM-dd'T'HH:mm:ss.SSSZ (i.e. which allows 2023-07-03T14:27:08.312+02:00 or 2023-07-03T12:27:08.312Z)
              example: "2023-07-03T12:27:08.312Z"

RefreshTokenCredential: accessTokenExpiresUtc

Code Block
              description: |
                REQUIRED. An absolute (UTC) timestamp at which the token shall be considered expired.
                In the case of an ACCESS_TOKEN_EXPIRED termination reason, implementation should notify the client before the expiration date.
                If the access token is a JWT and registered "exp" (Expiration Time) claim is present, the two expiry times should match.
                It must follow [RFC 3339](https://datatracker.ietf.org/doc/html/rfc3339#section-5.6) and must have time zone. 
                Recommended format is yyyy-MM-dd'T'HH:mm:ss.SSSZ (i.e. which allows 2023-07-03T14:27:08.312+02:00 or 2023-07-03T12:27:08.312Z)
              example: "2023-07-03T12:27:08.312Z"

startsAt

Code Block
          description: |
            Date when the event subscription will begin/began
            It must follow [RFC 3339](https://datatracker.ietf.org/doc/html/rfc3339#section-5.6) and must have time zone. 
            Recommended format is yyyy-MM-dd'T'HH:mm:ss.SSSZ (i.e. which allows 2023-07-03T14:27:08.312+02:00 or 2023-07-03T12:27:08.312Z)
          example: "2023-07-03T12:27:08.312Z"

expiresAt

Code Block
 description: |
            Date when the event subscription will expire. Only provided when `subscriptionExpireTime` is indicated by API client or Telco Operator has specific policy about that.
            It must follow [RFC 3339](https://datatracker.ietf.org/doc/html/rfc3339#section-5.6) and must have time zone. 
            Recommended format is yyyy-MM-dd'T'HH:mm:ss.SSSZ (i.e. which allows 2023-07-03T14:27:08.312+02:00 or 2023-07-03T12:27:08.312Z)
          example: "2023-07-03T12:27:08.312Z"

Sink format corrected and improved description of protocol and sink properties #414 #418 #421

sink parameter is defined twice - in the request and the response:

Code Block
sink:
  type: string
  format: uri

HTTPS should be used for notifications

Removed sinkCredential from Subscription schema in event-subscription-template.yaml in #400

Removed sinkCredential from Subscription (in the response) schema in event-subscription-template.yaml

sinkCredential is not present in Subscription response component in current API definitions