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
