that is about correct. I can imagine a statement in
advance by the TC, but what if the Draft got revised
largely? On the other hand, maybe if it, for example “use
TLS”, that the standard changed greatly is still within
specifications, we actually had some cross membership
between the TCs and the group that was working in the IETF
to update the specs we referenced. OASIS was able to get
to the finish line faster.
people have dropped off the TCs, essentially when their
corporate membership birthday cam up. I don’t feel good
about a small subset voting to “change” the spec either…
Thanks for the note!
While I share your view:
None of the changes I imagine involve moving anything to
later versions, just the completed versions then being
It's only my imagination that supports it.
I don't think it is possible to say, without detailed
examination, whether changes (say a superseded RFC) remain
compatible with the one cited by the TC. Perhaps a little
less dodgy from draft to final RFC, but the real issue is
who maintains an OASIS standard/specification after the TC
members have gone onto other standards work.
A more general solution would be to recognize that OASIS,
upon a Committee Specification or OASIS Standard AND, the
closing of the authoring TC, becomes responsible for
maintenance of the Committee Specification or OASIS
Standard. It should not be that hard to enumerate the things
that fall under maintenance:
1) Update citations for location or change from draft to
final status (What do we say when a standard is withdrawn?)
2) Update web addresses (upon request of users) when link
rot has resulted in links that fail. (including resource no
What else would we need? Defined tightly enough, it would
have no impact on IP obligations and would provide a means
for better maintenance without having to get TCs back
together for what are non-substantive changes.
Not to mention that prospective TCs, at least some of them,
may be thinking about long term maintenance and so this
would be another "service" that OASIS offers its members.
Would that be along the lines of what you were thinking
Hope you are having a great week!
On 07/10/2018 11:59 AM, Considine, Toby
I was looking through a
half dozen specs I was involved with a few years back,
and see the specifications are littered with some now
obsolete normative references. Some for example
referenced Draft RFCs that have now become actual
As you know, it is
always hard to "get the band back together". It was
always the intent of the TCs to reference the final
specs. None of the changes I imagine involve moving
anything to later versions, just the completed
versions then being worked on. All of them are
currently Committee Specs or OASIS Specs, so touching
them could be, well, problematic.
We have gone back and
forth on the correct process for this, going back so
far, even, as when I was on the TAB.
do we at last have a
process for this?
of the TAB, the summer editions of the 'IETF RFC
Citation List for OASIS Editors' and the 'W3CRecommendation
Citation List for OASIS Editors' are now
available. Please share as appropriate.
files collect the most current citations for IETF
RFCs and W3C Recommendations
together in individual files and formats them in
each organization's preferred manner. To cite a
given work in your specification, simply search
the text of the file and copy and paste the
citation into your document.
files are available here:
don't forget that you can find OASIS Standards and
Committee Specifications listed at https://www.oasis-open.org/standards.
We are working on a master OASIS citation list to
join the two already in place.
by The World Bank, OASIS, and
Technical Community Steward
OASIS: Advancing open standards for
the information society
Primary: +1 973-996-2298
Mobile: +1 201-341-1393
Technical Advisory Board, OASIS (TAB)
Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300
Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps)
Another Word For It (blog): http://tm.durusau.net