Fixes parsing of a 2.3 UICC profile.
This might be the wrong end as the spec says this is
NSI, but somehow it's working
Change-Id: I3cde1093156db274458d76e2c1c2e304d55a8466
The SAIP specification is very weird in a way that it treats the DF and
EF descriptions as some kind of flat structure without describing the
hierarchy. So when creating a DF, sometimes it should be created below
the current DF, and sometimes it should be adjacent next to the current
DF.
Let's introduce
* a 'ppath' property of FileTemplate to indicate if a file is anything
but a direct sibling of the 'base DF' of the PE
* an 'extends' property of ProfileTemplate to indicate that a given
template does not have its own 'base DF', but that its contents merely
extends that of another ProfileTemplate
* a 'parent' property of ProfileTemplate to indicate a parent
ProfileTemplate below whose 'base DF' our files should be placed.
Change-Id: Ieab4835cd21008b289713784c0eb7170af2ccfb9
This method can be used to expand the default value pattern of the
file system template for the file to the specified (record, file) length.
Change-Id: Id3eb16910c0bdfa572294e14ca1cd44ca95ca69f
The default value must contain '...' to indicate a variable-length
default value section, not '..'
Change-Id: I8d78278065c145b86460acf8eb723babe777c4f6
The SAIP specification version implicitly determines which filesystem
templates (or versions thereof) are supported. So if a given eUICC
states it implements SAIP version 2.3.0, then we have to translate
this into which template versions that means. The new SaipSpecVersion
and its derived classes do exactly that.
Change-Id: I3a894c72c22e42bd2067e067be80a67197ad1bf2
The SAIP data format is inherently flat and doesn't intrinsically
have an idea of the tree-like structure of a filesystem. However,
if we want to (for example) convert a physical USIM into an eSIM
profile, we need to find the template for a given file, where the file
is identified by its path.
Let's expose a path property of the FileTemplate object, and populate
that when creating the FileTemplate as part of a ProfileTemplate.
Change-Id: Ie145ba159081daf8fbfa544f6d4248f05b7eea96
We previously only permitted this for transparent files (TR), but
file size can of course also be specified for BER-TLV files.
Change-Id: Ie007cf2ccde0a17d0fb853a96b833f064ae52c59
There are e.g. templates for usim and for opt-usim, and they should not
be confused with each other. Let's reflect that in the naming.
Change-Id: Ic6d04ce3172dc969c6b8c018b8d305eb6fd3f550
pySim/esim/saip/templates.py:106:0: R1707: Disallow trailing comma tuple (trailing-comma-tuple)
pySim/esim/saip/templates.py:56:37: C0121: Comparison 'self.fid != None' should be 'self.fid is not None' (singleton-comparison)
pySim/esim/saip/templates.py:57:28: C0121: Comparison 'self.arr != None' should be 'self.arr is not None' (singleton-comparison)
pySim/esim/saip/templates.py:58:37: C0121: Comparison 'self.sfi != None' should be 'self.sfi is not None' (singleton-comparison)
pySim/esim/saip/templates.py:96:11: C0123: Use isinstance() rather than type() for a typecheck. (unidiomatic-typecheck)
pySim/esim/saip/templates.py:591:0: W1404: Implicit string concatenation found in list (implicit-str-concat)
Change-Id: I181578ba630c8bdb558297e990411b59593652a0
This adds classes for describing profile templates as well
as derived classes defining the profile templates of the
"Profile Interoperability Technical Specification", specifically
it's "ANNEX A (Normative): File Structure Templates Definition"
We need a machine-readable definition of those templates, so
we can fully interpret an unprotected profile package (UPP),
as the UPP usually only contains the increment/difference to
a given teplate.
Change-Id: I79bc0a480450ca2de4b687ba6f11d0a4ea4f14c8
