Subject: [precis] Should we define any subclasses of NameClass?

From: Dave Thaler <[email-masked]>
Date: Wed, 19 Oct 2011 23:03:09 +0000

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

---

From: Marc Blanchet <[email-masked]>
Date: Thu, 20 Oct 2011 06:49:00 -0400

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 :

> _______________________________________________
> precis mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/precis

---

From: Matt Miller <[email-masked]>
Date: Thu, 20 Oct 2011 09:24:39 -0600

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.

>> which is itself composed of two pieces with different classes (left side and right side of @).

- m&m

Matt Miller - <[email-masked]>
Collaboration Software Group - Cisco Systems, Inc.

---

From: Marc Blanchet <[email-masked]>
Date: Thu, 20 Oct 2011 15:25:04 -0400

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.

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.
> 
>

---

From: JFC Morfin <[email-masked]>
Date: Fri, 21 Oct 2011 12:36:57 +0200

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

---

From: Matt Miller <[email-masked]>
Date: Fri, 21 Oct 2011 07:37:16 -0600

> 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…

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