Add rationale for implicit account features

tips/TIP-0042/tip-0042.md

@@ -1051,7 +1051,34 @@ have implications for address validity. Moreover, the implicit account creation
 limited context, i.e. within an Address Unlock Condition in a Basic Output. These reasons warrant a separate address
 type.
 
-TODO: Describe utility of max `uint32` values for `Expiry Slot` and `End Epoch`.
+### Allowed Unlock Conditions and Features
+
+Features in implicit accounts are allowed to enable more seamless implicit account creation. The more permutations of
+Unlock Conditions and Features are allowed in Implicit Accounts, the more seamless implicit account creation becomes.
+None of the Basic Output features are problematic in implicit accounts, hence they are allowed.
+
+On the other hand, Storage Deposit Return, Timelock and Expiration Unlock Conditions are not useful for implicit account
+creation, so they are disallowed:
+
+- Storage Deposit Return: Having to return the funds on an implicit account to the sender means the full account that
+  needs to be transitioned to, must be funded by other means. In a typical onboarding scenario these funds do not exist,
+  so SDRUC would only make it more complicated to create the full account.
+- Timelock: Would be harmless, but timelocks are not permitted on full accounts either. It would be odd to be able to
+  use the implicit account to issue blocks (because the accounts ledger does not respect the timelock) but not be able
+  to do the implicit account conversion until the timelock expires.
+- Expiration: To fulfil syntactic rules, the `Return Address` would not be an implicit account creation address, but
+  some other regular address. Then for the `Address`, the Basic Output would be an implicit account, but for the
+  `Return Address` it would be a regular output, which is very undesirable behavior, since the `Return Address` would
+  not have to respect the account-locked mana rules, which would open an attack vector.
+
+## Expiry Slot and End Epoch
+
+One recurring pattern that applies to Staking and Block Issuer Features is the use of the maximum value of slot or epoch
+indices. The max value can be used to express that such features do not have an expiration set, applying to the
+`End Epoch` and `Expiry Slot`, respectively.
+
+Typically, one would want to set these features to not expire and only reduce the value to the closest possible one,
+once removal of the feature is desired.
 
 # Copyright