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.
