Specs precision needed about intent handler and app metadata intents property

[pgn-vole]

It is not clear reading the specification whether an application MUST have an intents property within its application definition in the appDirectory for a desktop agent to consider that application within the intent resolution logic.
A specification implementer may consider that an application just need to call fdc3.addIntentListener('IntentName') for it to be part of the intent resolution logic regardless on whether its app metadata has an intents property or not.
Could this ambiguity be clarified?

[kriswest]

@pgn-vole This is covered in the Desktop Agent overview under Register an Intent Handler

Register an Intent Handler

Applications need to let the system know the intents they can support. Typically, this is done via registration with an App Directory. It is also possible for intents to be registered at the application level as well to support ad-hoc registration which may be helpful at development time. Although dynamic registration is not part of this specification, a Desktop Agent agent may choose to support any number of registration paths.

However, its not particularly emphasized. In the Desktop Agent API Standard Compliance section there is also this statement:

An FDC3 Standard compliant Desktop Agent implementation SHOULD:

Support connection to one or more App Directories meeting the FDC3 App Directory Standard.

Although this does not relate specifically to registration for intent handling.

If you think this could be clearer please feel free to suggest a clarification. If that clarification doesn't alter the meaning of the standard we can push it into the current version, otherwise, it can be included in the next FDC3 release (and will show up in the 'next' version of the docs until released).

Note that you can edit this doc and raise a PR directly in github. Simply hit the pencil icon at the top of this page and edit the relevant content:

FDC3/docs/api/spec.md

Line 349 in afc85df

Applications need to let the system know the intents they can support. Typically, this is done via registration with an [App Directory](../app-directory/spec). It is also possible for intents to be registered at the application level as well to support ad-hoc registration which may be helpful at development time. Although dynamic registration is not part of this specification, a Desktop Agent agent may choose to support any number of registration paths.

My read of the current text is that an application SHOULD have an interop.intents.listensFor property (2.0 moved the old intents property to here) to allow the Desktop Agent to consider it for resolution (whether an instance of it has been started or not). Desktop Agents MAY support ad-hoc registration (i.e. considering them after an instance is launched and adds a listener), as well as other registration paths at their discretion.

The wording of the relevant statement for using apps starts with 'Typically', which should really be changed to a more definite statement using a compliance keyword (SHOULD). The last 'may' in the final quoted sentence above should also be capitalized (MAY). Finally, both statements should be repeated in the Desktop Agent API Standard Compliance section.

I would suggest the best way forward on this is to raise a PR which we can vote on at the next meeting.