Peter Saint-Andre wrote: > > On 10/7/10 3:12 PM, ArkanoiD wrote: > > > > It was my primary concern too, i definitely prefer simple and > > straightforward parsers that are less likely to behave any unexpected > > way :-) Once we agree to implement complex parsing, someone almost > > certainly will just use his favourite regexp library just because it > > saves time (causing total havoc) ;-) > > Exactly.
Full agreement. It is fine with me to cut sharp down to that functionality that rfc-2818 described and illustrated 10 years ago. But I believe it is not appropriate to turn an rfc-2818 effective SHOULD into a MUST NOT within a BCP unless there is a REALLY REALLY REALLY good rationale for it. I would be OK with deprecating it (SHOULD NOT). Personally, I do not see any problems implementing exactly the examples given in rfc-2818, but not more (i.e. single-wildcard substring matching on the leftmost label only). btw. "f*.com" is an rfc-2818 example that _my_ implementation of rfc-2818 matching unconditionally ignores when found in CN-ID or DNS-ID of a server cert--I require at least 3 labels when a wildcard is used. Should server-id-check promote "*.com" matching? (I think it should not). -Martin _______________________________________________ certid mailing list [email protected] https://www.ietf.org/mailman/listinfo/certid
