I am not sure that the discussion about constraints is the most pressing thing we need to talk about. ;-)
Anyway, as Martin already summarized, the usage of common name to identify a server is deprecated since the last millenium. It is nncoding of a *complete* identifier as a subcomponent of another one, something that can happen for non technical purposes, e.g. user friendliness etc. Building software based on such ad hoc approaches requires pattern matching logic, etc, not very difficult to implement but not necessarily easy to use. In fact, I think that the whole of defining a thingy CN-ID complicates the whole text, it should just be a small note indicating that is is a particular encoding of exactly one DNS-ID. It seems to me that the changes in the last version already go into this direction. Nevertheless, the last paragraph of 2.2 (starting with "We recognize") introduces (AFAIR) a string representation of a DN which doesn't serve any real purpose and which has a strange "hierarchy". Note, that one explains that a DN in X.500 is a hierarchy. The implementation note refers to what? I see some confusion regarding the example. Just because we have mentioned all kinds of adjectives during the discussion, I do not see the value mentioning them. The only one that matters is the the "(most specific)" mentioned in RFC 2818 IMO. There are some people knowning X.500 quite well: If one respects the non-normative schema rules, can one have more than one Common Name AVA in a DN? It has also been said that using the reerm "representation" is unfortunate. In corresponding texts (X.500 etc), the word 'indication' is used. I suggest to change this all over in the document. /P _______________________________________________ certid mailing list [email protected] https://www.ietf.org/mailman/listinfo/certid
