On Oct 20, 2011, at 13:25, Marc Blanchet wrote: > Le 2011-10-20 à 11:24, Matt Miller a écrit : > >> Personally, I think the bar for inclusion of classes ought to be higher than >> one protocol, > > maybe. but at least one... at the same time, if the bar is too high, we will > end up with not a framework useful, but a too small set that would have a lot > of profiles that changes the basic set. So there is a balance. >
I totally agree there's a balance that needs to be struck, and a criterion is "necessary for at least one protocol". My main point is that I think we should get consensus on what we have in front of us first, then look at subclasses. - m&m Matt Miller - <[email protected]> Collaboration Software Group - Cisco Systems, Inc. > Marc. > >> but I don't have a more definitive bar to set. The DomainNameClass most >> likely exceeds my nebulous bar, but I think we should get through the basics >> first. >> >> >> On Oct 20, 2011, at 04:49, Marc Blanchet wrote: >> >>> maybe useful, but I think we should do the "least" amount of classes, >>> criteria being that at least one protocol is using it. This would be for >>> the framework document. Obviously, a protocol can define a sub-class or >>> else. So if we see right now a protocol that would be using a new class, I >>> think it is a good idea to put it in the framework, otherwise leave it. >>> >>> Marc. >>> >>> Le 2011-10-19 à 19:03, Dave Thaler a écrit : >>> >>>> Currently NameClass is pretty generic. I'm wondering whether it would >>>> make sense to define any >>>> more complex concepts/subclasses. >>>> >>>> For example DomainNameClass might be a subclass with a specific set of >>>> default >>>> values of Valid, Disallowed, Case Mapping, etc. >>>> >>>> We might also define the concept of a ComplexClass, which would mean that >>>> the string has >>>> some internal structure (e.g., delimiter) where each portion might >>>> naturally map to another >>>> class (SecretClass, NameClass, or whatever). For example an email >>>> address is a ComplexClass, >>>> which is itself composed of two pieces with different classes (left side >>>> and right side of @). >>>> >>>> Useful or not useful? >>>> >>>> -Dave >>>> _______________________________________________ >>>> precis mailing list >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/precis >>> >>> _______________________________________________ >>> precis mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/precis >> >> - m&m >> >> Matt Miller - <[email protected]> >> Collaboration Software Group - Cisco Systems, Inc. >> >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ precis mailing list [email protected] https://www.ietf.org/mailman/listinfo/precis
