Update Get15118EVCertificateResponse.json

[HugoJP1]

At Switch, we have been running into an issue in 2.0.1 where certificates for the EV included in Get15118EVCertificateResponse are greater than 5600 (around 5800). This is because certificates have a lot of information embedded in them which can have variable length. We know that we haven't been the only company to encounter this issue, because it has been the focus of an OCA Technology Working Group meeting in early March. The provisional conclusion at that time was to increase the limit to 7500. This hasn't been formalised in a document yet, although I know that a follow up conversation is planned (see OCA notes from that meeting below)

Proposing to set to 7500 for now and then update once we get the full decision from the OCA.

• exiResponse field length limitation
  Long discussion on how to address this.
  There were some concerns that a charging station won't any longer be able to handle the message.
  The main problem is that we don't know how big the message will get because OCPP is only forwarding the messages and not defining them.
  Same problem for the -20 task group, because in the ISO15118-20 more and bigger certificates are allowed.
  Results:
  OCA will update the PnC 1.6 Whitepaper.
  The maximum length in the JSON schema will be dropped for the Get15118EvCertificate.conf message and the exiResponse field.
  The charging station shall report its maximum supported length of the field via a configuration variable.
  Additionally, there will be a recommendation regarding a reasonable length for the field (7500 chars).
  There will be a follow-up discussion on how to tackle this issue in OCPP 2.0.1.
  Franc created a JIRA Ticket for this https://openchargealliance.atlassian.net/browse/OCPP16M-67

[sonarcloud]

SonarCloud Quality Gate failed.   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
5.7% Duplication

[tropxy]

@OrangeTux does that sound reasonable for you?
also not sure why sonar cloud is complaining as it was one line change

[tropxy]

to add to the explanation on the top, Hubject onboarding document with the title "Requirements for EVSEs" says this:

3.2. Deviation from OCPP Message Get15118EVCertificate
The value of the FIELD NAME exiRequest/Response in the OCPP Message Get15118EVCertificate is limited to 5600 characters. This limitation is too low.
The EVSE shall accept strings for exiRequest/Response being a maximum of 7500 characters long but must accept exiRequest/Response being 6100 characters long.

I cant provide the full copy of the document, unfortunately, but I hope that is enough

[OrangeTux]

I'm not sure how to handle this situation, to be fair.

The OCPP 2.0.1 spec defines the limit as 5600 characters. I think this library should follow implement the specification. When the OCA makes changes to an existing spec, they should release the changes as part of a new version. For example as version 2.0.2.

I'm fine with adding preliminary support for this new version. Are you aware if the OCA is planning to release these changes under a new version, @tropxy ?

[HugoJP1]

@OrangeTux this is the current plan (from the draft errata of OCPP 2.0.1 due to be released officially soon):

[tropxy]

@OrangeTux this is the current plan (from the draft errata of OCPP 2.0.1 due to be released officially soon):

@OrangeTux given this, I think we shall include this PR into the base code, what do you say?