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: [security-services] proposal wrt "status"and"send comments to the editor"

Overall comment/thought -- it may well be UNreasonable to make all of these doc
metadata changes to the doc set we're attempting to coalesce this week. 

that said...

"Eve L. Maler" wrote:
> I seem to recall some weirdness about the way these x-comments lists are
> set up...

I sent a separate msg to the list entitled "Fwd: TC comment mail lists" that
explains how they're purported to presently behave. I believe it satisfies most
of your concerns. 

> In any case, I think listing this address is a good idea.


Actually, in thinking about it a bit more, I'm leaning towards ultimately
having something like..

  Security Services TC participants send comments to:

  Reviewers at large, send comments to: 

> [...]
> My idea in putting a Status: section on the first page was something like
> W3C's "Status of This Document" section, where you have a novel (not
> boilerplate) description of what's going on with the draft, what's been
> substantively changed, what sort of feedback is wanted, where to send
> comments, etc.
> I think it's a good idea (now that we have a canonical set of maturity
> levels) to have a line for it, but I also think the Status blurb is a good
> idea.  If we want to do this, though, we'll have to hop to it because it
> means writing some real text.

I think we're too late for this week to write a "Status:" blurb as you envision
it. However, I think it's probably a good idea for the next maturity level
(entering Last Call). The ITEF process also has a nominal "status of this
document" section so there's plenty of precedent. 

> >So, this would yield something like this on the first doc pages...
> >                 --------------------------
> >   Document identifier: ...
> >
> >   Location: ...
> >
> >   Publication Date: ...
> >
> >   Maturity Level: Committee Working Draft
> >
> >   Send comments to: security-services-comment@lists.oasis-open.org
> >
> >   Editors: ...
> >
> >   Contributors: ...
> [...]
> Could we add a "Status:" blurb at the end of this list?

nominally fine by me, but I'd suggest doing it a bit later on rather than this

> Oh, and should we or should we not have revision tables anywhere in these
> drafts?  I moved them to the first pages, but they don't have to be
> there.  In most cases, they don't provide any information that will help
> anyone decipher our drafts any more successfully...

I think we should pull them out when we prepare docs at "committee
specification" maturity level. Leave them in until then. 

> Finally, we should beware that the bibliographic references to other SAML
> drafts that appear in all our specs go "stale" quickly because the URLs in
> them mention draft numbers (e.g., bindings-08).  We need to check them all
> before we go live.  If we were to copy over each latest published draft
> into a generic "sstc-draft-bindings.pdf" file (etc.), it would be
> convenient then to change all the bib stuff once more, for good.

This is a hard one cuz it's messy any way we try to do it. If we do it via the
canonical "this is the url to the latest draft" as you suggest, then we have to
remember to update the "generic file" every time we put a new doc rev up in the
doc repository. Otherwise, the doc editors need to remember to go through their
bib sections and update appropriately. My experience is having to do the
latter, so I tend to lean that ways. I could be convinced to do the former I
suppose (but it adds to the responsibilities of the web site maintainer).


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

Powered by eList eXpress LLC