Which eUICC capabilities and how should SMSR use to segment SCP03t script?

Question

From section 5.4.4 of SGP.02-v4.2:

The SM-SR has the responsibility to build the final Command script, depending on eUICC capabilities and selected protocol

It is clear that in some cases SM-SR should split the command script that it received in data field of ES3.SendData. This is supported by examples from SGP.11-v4.0: compare step 14 on page 408 where complete profile package #PROFILE_PACKAGE is passed in ES3.SendData. with steps 3, 5 and 7 on pages 211-212 where segments in the form of #PROFILE_PARTi are sent via ES5.

First of all it is not clear what factors limit the capability to send the whole command script to eUICC. This question is important because the answer to it most probably would allow to answer the most important question: how exactly SMSR decides (as in what parameters it takes into account) how to split the command script.

I know about EUICC-CAPABILITIES but they only specify what transports/algorithms/features are supported. They do not give any hint of how large the single segment (that is #PROFILE_PARTi) of the command script built by SMSR can be. Also specification seems to distinguish eUICC capabilities from selected protocol and that's another factor that makes me think that capabilities mentioned in 5.4.4 are not the same as EUICC-CAPABILITIES.

SGP.11-v4.0 shows that even for CAT_TP or HTTPS segmenting should be used and SMSR somehow needs to decide how to split the command script it received.

So questions:

1. What eUICC capabilities should be taken into account by SMSR?
2. How exactly SMSR should use the capabilities to decide the size of the script segment (like #PROFILE_PARTi) it can use?
3. How SMSR can retrieve those capabilities for a given eUICC?
4. Can they be retrieved via means defined in some GP specification or is this manufacturer specific?

According to section 4.1.3.3 of SGP.02-v4.2 eUICC SHALL support profile command data segments of at least up to 1024 bytes (including tag and length field). Does it mean that:

1. SMDP will never create profile command data TLVs with code ‘86’ longer than 1024 bytes?
2. SMSR is compliant if it sends one command TLV at a time? (This way SMSR does not utilize the capabilities of the eUICC but this algorithm will work for any compliant eUICC regardless of eUICC’s capabilities.)

Answer 1

SM-SR:

1. Take a look into "EUICC-CAPABILITIES", sect. 5.1.1.2.10 for the supported transport features. For your implementation e.g. also the supported buffer size might be interesting to send as less concatenated SMS as possible or have a better TCP payload size. This must be implicitly known by reading the EID and know the features of the eUICC by interpreting the model and manufacturer. Not sure if yome eUICC are offering here more than the minimum.

2.+3.+4. Store the EIS when the eUICC is registered. (the SM-SR could have it in the database). This contains the EUICC-CAPABILITIES.

SM-DP:

1. Yes. Including the tag and length, MAC and padding. The profile package is sliced in 1020 byte chunks and then prefixed with the 86 tag and the 3 bytes length.

2. Yes, most likely, but like mentioned above a streaming protocol like CAT_TP or HTTPS does not have the problems of SMS.