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] | [Elist Home]


Subject: Re: Version


All,

>1) Version number
>    Should this be a number or a string?
>    Should there be any requirement for applications to take notice of
>      it (i.e. standard upgrade semantics, 1.1 extends 1.0, 2.0 is
incompatible)

I don't have a strong preference for either representation, but I would
like
it to be CONVERTIBLE to a number (i.e. NOT something like 1.2.13, which has
no corresponding numerical representation) so that at least after
conversion
you can use comparison operators like "<" or ">" on it.

>    Should the version be the schema string?

>    The fact that Chris used the schema string is leading me to strongly
>suspect that the Version attribute is actually redundant and that the
XMLNS
>attribute has the same function.

Not being an XML guru, I'm not really competent to address this.  However
if
there IS an existing XML structure which we can use then I would prefer
doing that
to introducing a new element.

My base position on this is that:

(1) It MUST be possible to determine the version of each SAML assertion
structure
(2) It SHOULD be possible to convert the version element associated with a
SAML
     assertion into a number
(3) Version identification MAY include both "major version" and "minor
version" but
     should not distinguish at a finer granularity than "minor version"
(4) Version numbers MUST be monotonically increasing with successive
revisions of the spec

Have I missed anything?

>    So far everyone is keen on the idea of a version attribute but
>unless someone can say how it is to be used I think we should yank it and
>rely on xmlns.

If this meets the criteria above I agree it's preferable

>    We need some text to describe what is going on either way.

Definitely

--bob

Bob Blakley (email: blakley@us.tivoli.com   phone: +1 512 436 1564)
Chief Scientist, Security, Tivoli Systems, Inc.


"Hallam-Baker, Phillip" <pbaker@verisign.com> on 07/31/2001 11:54:27 AM

Please respond to "Hallam-Baker, Phillip" <pbaker@verisign.com>

To:   "Security-Services (E-mail)" <security-services@lists.oasis-open.org>
cc:
Subject:  Version and Namespace issues



All,


1) Version number
     Should this be a number or a string?
     Should there be any requirement for applications to take notice of
it (i.e. standard upgrade semantics, 1.1 extends 1.0, 2.0 is incompatible)
     Should the version be the schema string?

     The fact that Chris used the schema string is leading me to strongly
suspect that the Version attribute is actually redundant and that the XMLNS
attribute has the same function.

     So far everyone is keen on the idea of a version attribute but
unless someone can say how it is to be used I think we should yank it and
rely on xmlns.

     We need some text to describe what is going on either way.

2) Namespaces

     The time has come folks, we need to take out the current date that
refers to the completion date of one of my direct ancestors successful
corporate takeovers.

     I propose using the following identifiers which will resolve to the
relevant docs in the repository:
http://www.oasis-open.org/committees/security/docs/yyyymmdd-assertion-draftn

n.xsd
http://www.oasis-open.org/committees/security/docs/yyyymmdd-protocol-draftnn

.xsd

where yyyy, mm, dd and nn are appropriately instantiated. Final versions
would be vX.Y



Phillip Hallam-Baker FBCS C.Eng.
Principal Scientist
VeriSign Inc.
pbaker@verisign.com
781 245 6996 x227







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


Powered by eList eXpress LLC