Personally, I think the bar for inclusion of classes ought to be higher than one protocol, 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
