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. Best Regards, John Voice US 845-435-9470 BluePages Tivoli OSLC Lead - Show me the Scenario
