Wire the device requisition parameter for enterprise enrollment.

chrome/browser/policy/proto/cloud/device_management_backend.proto

Index: chrome/browser/policy/proto/cloud/device_management_backend.proto
diff --git a/chrome/browser/policy/proto/cloud/device_management_backend.proto b/chrome/browser/policy/proto/cloud/device_management_backend.proto
index 0d42509b2bfd33e38a6c22192099f8df9d396981..4f414bd341e28d7a425de2fac38a9c6826ff5cc0 100644
--- a/chrome/browser/policy/proto/cloud/device_management_backend.proto
+++ b/chrome/browser/policy/proto/cloud/device_management_backend.proto
@@ -44,6 +44,11 @@ message DeviceRegisterRequest {
   // that the client is to be enrolled in the correct mode.
   // Defaults to false when not present.
   optional bool auto_enrolled = 5;
+
+  // Indicates a requisition of the registering entity that the server can act
+  // upon. This allows clients to pass hints e.g. at device enrollment time
+  // about the intended use of the device.
+  optional string requisition = 6;

[Mattias Nissler (ping if slow), 2013/05/13 10:52:35]

Bin, Raymond: I'd like to get your thoughts on this (or barring any thoughts, a
thumbs up).

[Bin, 2013/05/14 06:36:41]

Should we define some enum or we have to agree on some string values?

[Mattias Nissler (ping if slow), 2013/05/14 06:49:51]

I thought about this as well, but then decided to go with the string for
flexibility: If we have some new device type at some point, we can just let the
user enter a different requisition string and/or put new requisitions in the OEM
partition manifest.

[Bin, 2013/05/15 06:13:27]

My understanding (and also the comments indicates) is that this field should be
something the server understands and acts on. For example, we use this field to
indicate it is a vc device so the server can act differently.

You said the server can treat unknown values are an opaque string and just
record it down for the purpose of categorizing the devices. This is inconsistent
with the comment - "server can act upon".

My concern is that if we make it generic, people don't know what to put into
this field and if it affects server behavior. For some requisition values, the
server will act on them. For some requisition values, the server simply just
treat as opaque strings.

If we really want to keep this way, then please document the values which cause
server to act upon. Those values affect server-side behavior and should be
documented as part of protocol.


On 2013/05/14 06:49:51, Mattias Nissler wrote:

[Mattias Nissler (ping if slow), 2013/05/15 12:02:29]

No, it's just potentially so. We're essentially passing payload for a
higher-level protocol here: The client is telling the server what type of device
it is. The protocol itself doesn't need to (and IMHO shouldn't) define what the
available device types are.
It's not - I say the server _can_ act, so it doesn't have to. In fact, you can
just decide to return a 400 if the requisition the client is sending isn't
understood by the server.
Well, you could document somewhere that Google's DMServer does configure clients
as Kiosk device if you set a specific requisition. Or you could allow the admin
to define new requisitions in CPanel that assign the device to specific OUs at
enrollment time. The possibilities are endless, but all that is on an entirely
different layer than the guts of the client-server handshake at device
registration time.
I disagree. To make this clearer, let my make a comparison with TCP: There's a
port field in the message header. It allows us to route connections to the
appropriate endpoint. The TCP protocol spec doesn't say anything about what
services are to be expected on different ports and intentionally leaves the port
assignment problem to the user of the protocol. All this makes TCP flexible, not
fragile (which seems to be your main point of concern with the string field?).

 }
 
 // Response from server to device register request.