Clarification request on ensuring remote launches are supported by vendors. about cmi-5_spec_current HOT 3 CLOSED

All in all I think referring to "the session" is a little ambiguous, I know that Session is defined in the definitions.

I understand your point, but do you have a recommendation of how to make it less ambiguous? IMO there isn't much ambiguous about a term that is defined in a set of definitions. It is pretty unreasonable for them to make a leap from the word "session" which is defined in a set of terms in a specification to have it mean something other than that definition. Them requiring anything other than that the request uses the POST method and the full URL itself is beyond the scope of the spec and very likely to break implementations as you've pointed out.

I'd go much further than requiring cookie based authentication as being "annoying", it will just continue to break implementations going forward and although I suppose it isn't in technical violation of the spec, it certainly is in violation of the intent of the spec as you've pointed out.

I think since we've just seen a case in the wild of people ignoring the definition...

In general the WG has mostly disagreed with this stance historically, as people ignoring definitions can't generally be satisfied regardless of brevity.

(Note I'm all for clarifications, especially outside of actual "requirements", I just don't know what that clarity looks like in this case.)

from cmi-5_spec_current.

Hi @brianjmiller, Thanks for the reply,

I understand your point, but do you have a recommendation of how to make it less ambiguous? IMO there isn't much ambiguous about a term that is defined in a set of definitions. It is pretty unreasonable for them to make a leap from the word "session" which is defined in a set of terms in a specification to have it mean something other than that definition.

I'm not insistent on this at all, (and you say the working group doesn't seem keen on it) but I think the AU's session is much clearer. It disambiguates the term from the MANY technical meanings in order to make any implementor question themselves, and hopefully read definitions as they should.

Personally I'd like to be surprised by an unknown/scoped term which makes me consult the documentation and have to look it up or ask someone like you (thanks for the help so far).

although I suppose it isn't in technical violation of the spec, it certainly is in violation of the intent of the spec as you've pointed out.

Well put, how the specification could solve intent disputes is beyond me! It's hard enough to deal with a closed source vendor who seems willing to argue the spec on this one.. I might refer them to the definition section on session since they argued that it's their LMS session.

If anyone from the working group could somehow make some sort of clarification around the "purity" of the fetch process that would be great. By purity I mean that it shouldn't be stateful from the AU's prospective. The LMS should be encoding state in the fetch URL not via the browser.

from cmi-5_spec_current.

closed per Feb 9th meeting

from cmi-5_spec_current.