In Declarative Device Management there is the Get Server Supported Declarations endpoint that is sent via an MDM Check-In request. Is this supposed to return all of the declarations supported by the server, or only the ones that are intended for the device making the request? This seems like a bad choice of naming for that endpoint and, if my assumption is correct it should be named more along the lines of "Get Device Declarations" Or am I fundamentally misunderstanding DDM and our server should be sending all declarations we have to the device and the device controls them via activations? This seems counter to the pitch around scalability and performance improvements that DDM offers if we have to send literally everything to the device even if it's known to not be needed, and similarly if the device doesn't support it but the server does then obviously(?) the server shouldn't send it to the device.

Can someone please explain the purpose of the ManagementServerCapabilities declaration in Declarative Device Management? I understand based on the documentation that it contains a "dictionary that contains the server’s optional protocol features" but what would be an example of an "optional protocol feature"?

We are currently implementing the Notifications API for Apps & Books and are seeing frequent (90%+) failures when handling these requests. We're using ASP.NET Core 6 and are seeing System.OperationCanceledException implying that the Apple servers are cancelling the request while our service is processing it. There is no documentation to indicate that the API has a specific timeout and we can't see anything at fault with our code, nor can we reproduce it with test requests. Has anyone else seen similar cancellation / timeout issues with the Notification API?