OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Additional suggestions for naming changes

This completes an action item I took in the May 11 telecon.

I went for aesthetics as much as brevity and consistency in the
following list, using cues from speaking and whiteboard-writing
patterns.  Since choosing to abbreviate means that you have to
apply *some* value judgment (as opposed to simply spelling out
the name as the Deity intended :-), this was necessary.

(Having read through the schemas closely, I have to say that I
like the overall effect of the truncation changes we made last
week. BTW, we'll be uploading those changes Real Soon Now...
Doing a little bit more in this direction could be good.)

I'm not sure I like all of the following, but I thought I would
list all the plausible possibilities and see what people think.
Here's a summary of the following sections:

Qualifier -> Qual
Reference -> Ref
Statement -> Stmt
Confirmation -> Conf
Condition -> (null)
Reauthenticate -> Reauthn
Attribute -> Attrib or Att
Service -> Svc
Assertion -> Assn

Qualifier -> Qual

I give this one a C grade.  It doesn't look that good, and
people don't really elide the "ifier" when they talk.  I suppose
"Qualif" is an option, but it doesn't save that much.

In saml:BaseIDAbstractType:

In samlp:NameIDPolicyType:

Reference -> Ref

I give this one an A grade.  People do talk about "refs", and the
names in which Reference appears are long enough already.


Statement -> Stmt

I give this one an F grade, so I'm not going to bother listing
all the things it changes.  (I do frequently use this
abbreviation when writing, to be honest.)  If people are
interested, I can list all the locations.

Confirmation -> Conf

I give this one a C grade.  The "nf" combination is tough and
unnatural to say, even though the word gets shortened
considerably.  Alternatively we could shorten Confirmation to
Confirm, but then it sounds like a verb, which is not a naming
pattern we've used outside of the protocols.


Condition -> (null)

I give this one an A- grade.  The names are perfectly evocative
without Condition -- words like "restriction" and "use" describe
conditions -- and the elements are still of type Condition.
The only ding against it is that it breaks our previous naming

(saml:Condition remains the same)

Reauthenticate -> Reauthn

I give this one an A- grade.  I'm tempted to suggest just Reauth
without the "n", since people might actually say that (and not
confuse it with "reauthorize"?), but that really does go against
the pattern we've just started adopting.

In saml:StatementAbstractType:

Attribute -> Attrib or Att

I'm not sure what to think of this one.  It would affect a lot of
things; I haven't listed them all yet.  I frequently truncate
them when writing them out, with "attrib" being more
identifiable; I would tend to say "att" and not "attrib" when
speaking, but would rarely say either one.  Note that we've now
truncated its two companions, Authn and AuthzDecision.

Service -> Svc

I give this one a B grade.  It's all consonants and therefore
ugly, but is relatively common.

In samlp:RequestAbstractType:

Assertion -> Assn

(Notice I didn't suggest "Ass." :-)  I don't particularly like
this one; I frequently write it in truncated form, but since
assertions are so essential to the SAML model, I'm reluctant to
take away its "dignity".  I haven't listed all the places

Eve Maler                                        +1 781 442 3190
Sun Microsystems                            cell +1 781 354 9441
Web Products, Technologies, and Standards    eve.maler @ sun.com

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]