> From: John Arwe/Poughkeepsie/IBM@IBMUS > To: [email protected], > Date: 09/01/2011 04:32 PM > Subject: [oslc-core] awkward statement in Core on pre-filling creation dialogs > Sent by: [email protected] > > http://open-services.net/bin/view/Main/OslcCoreSpecification? > sortcol=table;table=up;up=#Dialog_Resizing then page up > > Prefilling Creation Dialogs > Service providers MAY support receiving a POST request whose content body is > a change request resource definition to the Creation Dialog URI to retrieve > a URI that represents the embedded page to be used. Service providers MUST > respond with a response status of 201 (Created) with the response header Location > whose value is the URI to request the newly created form. Service providers MAY NOT > maintain the created form in a persistent storage. Clients SHOULD expect
> that after some elapsed time, a GET on these transient response URIs MAY > result with response status codes of 404 (Not found) or a 3xx (Redirect). > "MAY NOT" could be read to mean "MUST NOT" or "MAY" ... if the intent was to > allow implementations to do whatever they want, dropping NOT reads no worse > and conveys the intent clearly. Assuming that same intent, if the purpose > of using MAY NOT in the original was to gently nudge readers towards > thinking "bad idea, why would I do that", then SHOULD NOT or NOT RECOMMENDED > might be more appropriate. I think this may have been a case of RFC-2119 upcasing. I think the intent of that original statement is informative in saying that servers may (or may not) persist something on the server. Just because you receive a POST request, it is possible to respond with a new URL in the Location header with a 201 response. I might recommend that the upcasing and choice of words be reconsidered. Such as "Service providers MAY maintain the created form in a persistent storage." but does that really make it any better. Other suggestions welcome Thanks, Steve Speicher | IBM Rational Software | (919) 254-0645
