Gen-ART editorial comment

[mnot]

This paragraph in section 4 struck me oddly:

An extension member (see Section 3.2) MAY occur in the Problem field if its name is compatible with the syntax of Dictionary keys (see Section 3.2 of [STRUCTURED-FIELDS]) and if the defining problem type specifies a Structured Type to serialize the value into.

That almost sounds like what you want to say is:

If an extension member (see Section 3.2) occurs in the Problem field, its name MUST be compatible with the syntax of Dictionary keys (see Section 3.2 of [STRUCTURED-FIELDS]) and the defining problem type MUST specify a Structured Type to serialize the value into.

I'm curious if you are making a normative statement that would get lost in the current form. But I'm not sure what the high-order bit here is, so I leave it to you.

[dret]

it seems to me that the updated version captures the goal better than the original. after all, we want to disallow fields that aren't well-defined or serializable. a general problem with this snippet (independent of the rewording) is that "type" is optional, so technically there isn't always a "defining problem type". do we want to address this case explicitly (either in the old or in the new wording)?

[mnot]

Type is optional, but it defaults to something well-defined, so I don't think that's an issue.