Subject: IANA Update: Project to convert registries to XML

From: Michelle Cotton <[email-masked]>
Date: Mon, 14 Jul 2008 15:04:07 -0700

IETF Community:

As first announced in April 2008, IANA is improving the formatting of its
protocol registries by migrating the source format of these registries to
structured XML format. We are pleased to announce the first set of migrated
registries have now come online.

Prior to this migration, typically protocol registries were formatted in a
plain text version. Now, with XML formatted source documents, IANA will
publish a number of different formats for converted registries. In
particular, converted registries will initially be available in XML, XHTML
and plain text versions.  It is intended that XHTML become the preferred
format for viewing registries, with plain text being made available for
accessibility reasons.

The remainder of the registries which are not yet converted require further
consultation on formatting issues. It is intended that over the coming
months these issues will be resolved and the conversion will be completed.
Some registries that have specific formatting requirements, such as
Management Information Base (MIB) files, will not be converted.

In order to make the transition as smooth as possible, IANA will continue to
maintain the legacy plain text formats until 30 November 2008. After this
date, plain text versions will only be provided that are derived from the
XML formats. However, implementors who intend to parse the contents of an
IANA protocol registry should migrate to using the XML versions, rather than
the plain text version.

All existing URLs to protocol registries shall continue to work, and the new
formats will be available from our website at http://www.iana.org/protocols/
as they are rolled out.

An example of a converted registry is:
http://www.iana.org/assignments/aaa-parameters (legacy text version)
http://www.iana.org/assignments/aaa-parameters/aaa-parameters.txt (new text
version)
http://www.iana.org/assignments/aaa-parameters/aaa-parameters.xhtml (new
HTML version)
http://www.iana.org/assignments/aaa-parameters/aaa-parameters.xml (new XML
version)

The next steps (in addition to completing the remaining registries) includes
introducing new services such as the ability to subscribe to be notified of
registry changes. IANA will continue to provide updates to the IETF list as
more steps are completed.

If you have any questions regarding this project or regarding the format of
the registries, please contact IANA ([email-masked]) or myself (contact
information found below).

Thank you,

Michelle Cotton
IANA IETF Liaison
Email: [email-masked]

***

Initial Announcement:  Wed, 23 Apr 2008
Subject: IANA Update: Project to convert registries to XML

IANA is currently engaged in a project to convert the IETF related
registries to XML to provide the community with multiple ways of
viewing registry information.  When conversion to XML is done, XML
will become the source format for the registries and the current
formats of html and plain text will be generated from the XML
source.  Stylesheets and schemas will also be made available together
with XML. Users will be able to access the registries in new and
useful ways, while still having the ability to see the registries in
the original style.

Part of the conversion requires IANA to "clean-up" the registries in
order to fit with the XML schemas.  IANA is not changing the data in
the registries.  IANA is cleaning up the formatting including
regularizing spacing and providing consistent display of titles,
references and registration procedures.

For those registries that need extensive format changes, IANA will be
working with the appropriate working groups and area directors to
make sure that the format changes do not affect the content of the
registry.

Those registries that are required to be in specific formats, for
example the MIBs and language subtags registries, will still be
produced in the existing formats.

IANA has consulted with the IETF XML directorate to make sure that
the XML schemas are properly formulated. Certain decisions on schemas
reflect the needs of IANA in maintaining the registries moving forward.

In the coming months, cleaned-up versions of the registries will
begin appearing on the IANA website.  If you notice any content
issues with the updated versions, or if they are not accessible,
please notify IANA staff immediately and we will work with the
appropriate parties to correct any inconsistencies.

We look forward to providing the XML versions of the registries to
better serve the community's needs.  IANA will announce in advance when
the registry conversion will be completed.  After the
conversion is complete, we intend to introduce new services such as
the ability to subscribe to be notified when specific registries are
updated

Thank you,

Michelle Cotton
IANA IETF Liaison
Email: [email-masked]

_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Julian Reschke <[email-masked]>
Date: Tue, 15 Jul 2008 13:18:23 +0200

Hi,

this looks really good; a simple XML format, XSLT provided, registry 
served both as XML and proper XHTML.

Here are a few question/suggestions though...:

1) When you say

> formats will be available from our website at http://www.iana.org/protocols/

...is that just for a transition period? Will the new formats eventually 
served for the old URLs?

2) I think it would be good to have stable HTTP URLs both to registries 
and individual registrations. For "simple" registries, would it be 
possible to assign predictable and stable id attributes to the XML (and 
the XHTML), so linking to fragments would work?

3) Registry format: I like registries that not only reference RFCs, but 
also tell their readers which section of the document has the reference. 
Will this be supported as an option?

4) Finally an idea for future work: use GRDDL 
(<http://www.w3.org/TR/grddl/>) to extract RDF from the registries.

BR, Julian

PS: Are people involved with this present in Dublin?
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: James Cloos <[email-masked]>
Date: Fri, 18 Jul 2008 14:31:18 -0400

This is a useful progression.  But there still must be an easy and
efficient way to mirror the whole repository.

It appears that this change broke ftp and rsync access, the only
reasonable methods of mirroring the old repo.

You need to either make the full repo available via rsync and ftp
or -- even better -- publish it via a distributed revision control
system such as git, mercurial or bzr.

The ability to have a full, local, offline mirror is /important/.
As is efficiency -- downloading changes rather than whole files.

-JimC
-- 
James Cloos <[email-masked]>         OpenPGP: 1024D/ED7DAEA6
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 21 Jul 2008 20:46:58 +0200

On Fri, Jul 18, 2008 at 02:31:18PM -0400,
 James Cloos <[email-masked]> wrote 
 a message of 20 lines which said:

> But there still must be an easy and efficient way to mirror the
> whole repository.

I fully agree.

> system such as git, mercurial or bzr.

Why a dVCS? Any VCS would make it, and Subversion, for instance, would
be a good choice. If we use a dVCS, I vote for darcs.
 
> The ability to have a full, local, offline mirror is /important/.

+1

---

From: James Cloos <[email-masked]>
Date: Mon, 21 Jul 2008 16:29:30 -0400

>>>>> "Stephane" == Stephane Bortzmeyer <[email-masked]> writes:

Stephane> Why a dVCS? Any VCS would make it, and Subversion, for
Stephane> instance, would be a good choice. If we use a dVCS,
 
More efficient.  Everything works better with local history.  Svn wastes
a lot of disk by keeping two copies of every file in each checkout.  At
least a dVCS can compress the store.

Stephane> I vote for darcs.

Doesn't darcs have a bug they can't fix?  esr's recent survey of the
dVCSs concluded that git, hg and bzr are the best choices.  He
considered performance, as well as community involvement and how many
other projects are using each dVCS, on the theory that bugs get fixed
faster when more people use it.

-JimC

(As a side note, my initial mention of rsync breaking was a misnomer.
My rsync job only grabs rfcs and i-ds.  I had conflated that with a
request I sent some months (years?) back to make ftp.iana.org rsyncable.
It is only ftp which hadn't been updated since April.  And in a off-list
reply IANA said they plan to fix that.)

---

From: Michelle Cotton <[email-masked]>
Date: Mon, 21 Jul 2008 14:27:51 -0700

FTP access to the assignments directory has been restored.  It may take up to 24 hours to properly resolve ftp.iana.org.

As James mentioned in his message below, rsync was never operational, however we plan to make that available in the next few weeks.
We are also working on other new services such as the ability to subscribe to be notified when specific registries are updated.

Thanks again for the feedback.

Michelle Cotton
IANA

-JimC