The Subject Distinguished Name (Subject DN) is an ordered sequence of relative distinguished names (RDN), and each RDN is an unordered set of attribute value assertion (AVA). An AVA is something like "CN=yourname" or "O=yourorganization" (although they're not store like that in the certificate).
Most of the time, there will only be one AVA per RDN, so, unless it's an odd case, it's often acceptable to call this the Subject DN's CN RDN for example (or even a "field" I guess, if you don't need to be too specific).
There are multiple standards for serializing a Subject DN into a readable string, in particular left-to-right or right-to left, or E= v.s. emailAddress=, or coma or slash separator. You should first make sure you tool is able to read them from their OID (Object Identifier) rather than the string representation.
Often, the sequence will be country, organization, organizational unit, common name and perhaps e-mail (although e-mail address is always problematic since it's once of those that don't always serialize into a string in the same way depending on the standard used).
In general, CAs are free to do what they want in terms of structure of the Subject DN, and whether or not they use the subject alternative name extensions. These things tend to be regulated by each CA policy (which can be quite long technical and legal documents). There is no one size fits all in this domain.
Before accepting client-certificates, you should make sure you agree with their policies. Once you trust a CA certificate, the PKI model is such that it's hard to do fine grained selection after that.
The list of trusted CAs depends on the platform and the configuration. By default, Java on OSX has about 150 CA certificates in its truststore, on other platforms it's about 70, I think. These numbers can vary substantially.
Anyway, if you do want to accept client certificates, you more or less need to know where they come from, so quite often, you will have a small subset of CAs you're willing to trust for that. I'd definitely recommend to configure which CAs you're willing to trust for client-certificate authentication after a careful manual selection (based on the policy documents).
In practice, I'm not sure why clients would send their certificate randomly to any server, just like that. PKIs for client certificates, tend to work better in a closed administrative domain, or within a well-established federation, in which case you and your users will belong to those organizations and you'll know which CA to expect.
In addition, I'd suggest limiting the use of client-certificates for authenticating a user, while fetching further attributes from somewhere else, like and LDAP server. Typically, client-certificates will be emitted to an individual for a year or more, whereas the information about the individual (even organizational unit) may change in practice. All of this has to be considered if you want to use a CA or set up your own.
