Kris West

@dominicgifford happy to add optional elements where they make sense for shared context. What would you suggest for adding: - strategy (optional string field)? - break down by tax lots...

If the interaction types can't be an exhaustive list as an enum, I see no harm in adding a suggested list to the docs with a SHOULD recommendation to at...

Hey @pauldyson I had a look into what it would take to create an extensible field for `interactionType`, (so that we can encourage standard types but leave it open to...

- Balance of opinion at #481 was that we should proceed with further discussion, but as an optional part of the specification (MAY) - Proposals to be raised or further...

PR is based off of #747 and should not be merged until that has been, unless it is rebased on master first.

@milindchidrawar @pauldyson I've dropped you a PR with some suggested tweaks (as discussed at today's meeting).

Should we just drop the displayName field from IntentMetadata (which leaves it as a rather pointless class containing only a single string `name`) ? After all intents should be: -...

@ggeorgievx any thoughts on how to resolve this issue? I can see how this flaw might have come about: - There exists suggested display names for the standard intents: https://github.com/finos/FDC3/blob/master/src/intents/standard%20intents.json...

I agree that this change makes sense. The semantics of AppIntent have always bothered me as has the hack you have to use to pick a display name for intents....

One more thing to consider... Rex suggested this in the deprecation policy (see #532): > Rather than quietly change the behavior of an existing feature, consider deprecating it and replacing...