[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [security-services] Additional suggestions for naming changes
I think the rationale should be that we abbreviate only "long" terms that have a fairly well-known abbreviation. In the case of authentication and authorization, that would apply as they are 14 and 13 chars respectively and Authn and Authz are common shortcuts. I'd prefer to not shorten "short" terms (e.g. Service). I wonder if a cutoff should be anything, say, 10 chars or more. > > Reference -> Ref yes [Rob] no > Condition -> (null) yes [Rob] ok > Confirmation -> Conf maybe [Rob] No - ambiguous abbreviation for "configuration" > Attribute -> Attr maybe [Rob] no > NameQualifier -> Qualifier maybe [Rob] haven't decided. > Assertion -> Assn no? [Rob] no - ambiguous with association > Service -> Svc no [Rob] no > Qualifier -> Qual no [Rob] no > Statement -> Stmt no [Rob] no > Reauthenticate -> Reauthn no [Rob] no > > If people can weigh in so that we get a clearer idea of the leanings, it > sounds like Scott can implement, in proposed form, the ones with the > most support. > > To continue my weigh-in here, I don't think NameQualifier -> Qualifier > is a good idea because the parent element is not Name, but rather BaseID. > > Eve > -- > Eve Maler +1 781 442 3190 > Sun Microsystems cell +1 781 354 9441 > Web Products, Technologies, and Standards eve.maler @ sun.com > > > To unsubscribe from this mailing list (and be removed from the roster of > the OASIS TC), go to http://www.oasis- > open.org/apps/org/workgroup/security-services/members/leave_workgroup.ph p.