Update specification.md

Co-authored-by: Ricardo Zanini <[email protected]>

Author: cdavernas

specification.md

@@ -4385,7 +4385,7 @@ Represents the workflow's error handling configuration, including error definiti
 | Parameter | Description | Type | Required |
 | --- | --- | --- | --- |
 | name | The name of the error. Must follow the [Serverless Workflow Naming Convention](#naming-convention) | string | yes |
-| instance | An RFC6901 JSON pointer that precisely identifies the component within a workflow definition (ex: funcRef, subflowRef, ...) from which the described error originates. | string | yes, but is added by runtime when throwing an error |
+| instance | An [RFC 6901 JSON pointer](https://datatracker.ietf.org/doc/html/rfc6901) that precisely identifies the component within a workflow definition (ex: funcRef, subflowRef, ...) from which the described error originates. | string | yes, but is added by runtime when throwing an error |
 | type | A RFC3986 URI reference that identifies the error type. The RFC7807 Problem Details specification encourages that, when dereferenced, it provide human-readable documentation for the error type (e.g., using HTML). The specification strongly recommends using [default error types](#error-types) for cross-compatibility concerns. | string | yes |
 | status | The status code generated by the origin for an occurrence of an error. Status codes are extensible by nature and runtimes are not required to understand the meaning of all defined status codes. However, for cross-compatibility concerns, the specification encourages using RFC7231 HTTP Status Codes. | string | yes |
 | title | A short, human-readable summary of a error type. It SHOULD NOT change from occurrence to occurrence of an error, except for purposes of localization. | string | no |