Re: [security-services] EDITORIAL: accessing the "latest" versions ofSAML documents

["Eve L. Maler" <Eve.Maler@Sun.COM>]

Silly me, I forgot to actually try Kavi's full functionality in this 
respect.  It does indeed have a document revision function.  However, I 
just discovered that it assigns a new download ID for every revision of 
the same document with the same name!  So there's not enough benefit in 
doing the revision-less thing to make it worth it; in fact, I now think 
it's downright confusing (dangerous?) because, as you'll see if you look 
at my recent sstc-saml-scope-2.0.sxw upload experiment on the Documents 
page, you can easily have two documents with identical names show up as 
peers even though one was uploaded as a revision of the other.

So let's not change how we were doing things; let's continue to be 
"revision-ful" for all documents.  I'll just update the home page 
periodically to scoop up any doc revision link changes.

Now I'm REALLY glad that we settled on adding things like "draft-nn" to 
our filenames in the beginning.

Oh, and I owe JeffH an apology. :-)

	Eve

Eve L. Maler wrote:

> 
> As agreed at this week's editorial team meeting, we're going to
> start making the SAML specs and auxiliary documents available in
> a new way from Kavi.
> 
> (Work item owners and other use case/solution proposal writers:
> Note that this does not concern you!  You can keep doing whatever
> it is you're doing regarding filenames and uploading to Kavi.
> However, if you feel like adopting the mechanism detailed below,
> go for it.)
> 
> For auxiliary documents such as the scope/work items document and
> the issues list, I will be moving to a "revision-less" style,
> where filenames will be denuded of their rev numbers.  Example:
> sstc-saml-2.0-issues.pdf.  These documents contain all the
> history and context any reader would need, so there's no need to
> go back to a previous rev.  Kavi will be the only thing keeping
> track of the old revs.
> 
> For specifications, the editors have agreed to upload both
> revision-ful *and* identical revision-less forms for each new rev
> of a spec, and to provide a bit more information on the title
> page of each rev to point people to the previous rev for their
> convenience.  See below for my proposal for how this additional
> info should look.
> 
> The benefit is that the revision-less forms will get persistent
> download IDs in the Kavi system, and thus persistent URLs.  Once
> this process is complete, people will be able to bookmark the
> "latest" versions of any of our documents, and we'll have an
> easier time keeping the handcrafted links on the SAML public and
> member home pages up to date.  However, for (say) implementors
> who want to point to the specific rev that they conform to, or
> people who need to cite a specific line number in reporting a
> comment, a revision-full form will still be referenceable by URI.
> 
> Read on only if you're an editor or you have a morbid interest in
> publication stuff...  Feel free to send comments or questions.
> 
>             *        *        *
> ...
-- 
Eve Maler                                        +1 781 442 3190
Sun Microsystems                            cell +1 781 354 9441
Web Products, Technologies, and Standards    eve.maler @ sun.com