LRS can support additional resources

[garemoko]

Consider adding something to https://github.com/adlnet/xAPI-Spec/blob/master/xAPI.md#71-error-codes to say that the LRS can support additional resources not in the spec and add error code 405 to the list of example codes.

See https://github.com/adlnet/xAPI_LRS_Test/issues/24

[fugu13]

We don't really need to say that an LRS can support additional resources, that's just part of the nature of the web, but if people want to put it in, that's fine too. I'd actually think some positive language about possible future endpoints might be good, maybe "If additional endpoints are added to the spec, every path segment specified will start with a letter". That would mean LRS developers could safely stick their own resources in various places by starting with something other than a letter in part of the path.

[garemoko]

That's an interesting approach. To follow the pattern from statement structure, could we say that future endpoint will never start with "extensions/" and possibly add in a SHOULD to locate additional end points there. I'm aware of at least one LRS already not following this, but if it's a SHOULD, that's ok.

[garemoko]

This one also needs discussion on a call to determine:

• Whether or not we want to commit to the broad approach outlined by @fugu13
• The detail of how we'll implement it (see my suggestion and @fugu13's original suggestion as possibilities)

[andyjohnson]

Per the 3/18/15 call, like both approaches, but no decision made on which one. Requirement would be a SHOULD*

[fugu13]

I don't think they need to be exclusive; we could easily allow for both options, and this is an area it's reasonable to be expansive

[garemoko]

That PR never added 405 to the list of possible error codes. See adlnet-archive/grail-issue-tracker#55