At 12:49 20/10/2011, 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.
I wonder if classes should be individually defined or if only the
class concept would be enough at this stage. What could be defined
are more precise criteria (e.g. accept spaces or not, accept upper
cases or not, etc.). Classes would then be criteria containers. Then
a mnemonic system could be defined to abbreviate a list of criteria
into a name. This would be something similar to owner or mode in
Unix. We could even consider the chclass command concept.
jfc
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
_______________________________________________
precis mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/precis