I had been trapped in this Get_Descriptor issue, too, when I started USB study :-)
"9.4 Standard Device Requests" section of USB2.0 spec describes about Get_Descriptor as a Standard Device
Request. But it doesn't mean Get_Descriptor is not applied to any recipient other than Device. This section defines the way how the device has to interpret the request, just when bmRequestType is 0x80 (Standard Device Request).
HID spec also defines Get_Descriptor at "7.1.1 Get_Descriptor Request". In this section, HID spec describes just when bmRequestType is 0x81 (Recipient is Interface
). There is no inconsistency with the original USB2.0 spec, here.
The Common Class Specification ( http://www.usb.org/developers/devclass_docs/usbccs10.pdf
) explains on this Get_Descriptor issue, as follows.
3.11 Identifying Class and Vendor-Specific Requests and DescriptorsThe standard GET_DESCRIPTOR request (with the bRequestType.Type field set to standard) is used to directly request class or vendor-specific descriptors. The class associated with such a request is determined by the class of the bmRequestType.Recipient. When the bmRequestType.Recipient field is set to INTERFACE or ENDPOINT, the wIndex field identifies the desired interface or endpoint. All endpoints within an interface use that interface’s class, subclass and protocol.
The lesson I had gotten on this issue was twofold,
1) Request parsers have to check all fields on the SETUP data with those specified on the spec. If any field doesn't match, the parser should not process the request.
2) Just after SETUP transaction comes, device stack passes it to a parser of Standard Device requests. And then, the stack passes the request to a callback of Class/Vendor parsers. In a HID Class parser, this Get_Descriptor of Interface has a chance to be parsed.
These parsers raises a flag when they process the request. If no one handles the request, the device stack STALLs the request.
In this code flow, you may separate class implementation beautifully from the basic stack code.