UA Colleagues:
I think the problem Michael points out is a real one, and worthy of attention.
On 2019-01-08 07:03, Michael Casadevall wrote:
So currently, the UASG publishes various documents such as UASG 0005 andMichael proposes one alternative,
0007 and occasionally updates these documents to reflect best current
practices. For example, the UA Quick Guide was on Version 9 before it
was removed for revision.
One thing I'm concerned on is that it's not clear that a document has
been updated, nor what has changed from version to version. Furthermore,
when dealing with old discussions, a document may have changed from a
message or posted....
…to change the numbering and management of UASG documentation
to model it around the RFC/IETF where a document is static once
published (with errata linked), and is obsoleted/superseded by future
documents.…
Another alternative is to keep the document number unchanged, but to have a clearly-defined revision date for each version of a document, and to always cite a revision date along with the document number. So, we would say "UASG012 Email Address Internationalization (EAI): A Technical Overview (v 2018-05-12)" instead of "UASG012" or "Email Address Internationalization (EAI): A Technical Overview".
Whichever we do, I believe we should set editorial standards that each document has a) document title, b) UASG number, and c) revision date clearly on the front cover and in the file name of each document issued. Looking through some existing documents, we seem to be inconsistent about this. It makes documents harder to find and harder to cite.
I believe we should also define standard, persistent URLs for each document, something like:
http://uasg.tech/document/uasg012/email_address_internationalization_EAI_a_technical_overview/2018-05-12/
and ensure that visiting such a URL with a web browser returns either the document file itself, or a page describing the document and allowing one to download it. I find it hard to put links to UASG documents into presentations, because it's difficult to figure out which URL to use, and how much to trust it to stay usable over time.
Best regard,
—Jim DeLaHunt, Vancouver, Canada