Subject: [Enum] Example XML chunk for enum-services [IANA #171390]

From: Michelle Cotton <[email-masked]>
Date: Wed, 15 Oct 2008 13:31:19 -0700

Bernie, all.

>From draft-ietf-enum-enumservices-guide-12, Section 5.2, below is an example of what the XML chunk could look like.

<record>
  <class>Protocol-based</class>
  <type>foo</type>
  <subtype>bar</subtype>
  <scheme>bar</scheme>
  <scheme>bars</scheme>
  <spec>
    This Enumservice indicates that the resource identified can be
    addressed by the associated URI in order to foo the bar. [...]
  </spec>
  <security>See <xref type="rfc" data="rfc9999"/>, Section 7.</security>
  <usage>COMMON</usage>
  <xref type="rfc" data="rfc9999"/>
  <xref type="person" data="John_Doe"/>
  <xref type="person" data="Jane_Dale"/>
  <info>Further information free text...</info>
</record>

<person id="John_Doe">
  <name>John Doe</name>
  <org>ACME Corp.</org>
  <uri>mailto:[email-masked]</uri>
  <updated>2008-10-10</updated>
</person>
<person id="Jane_Dale">
  <name>Jane Dale</name>
  <org>ACME Corp.</org>
  <uri>mailto:[email-masked]</uri>
  <updated>2008-10-10</updated>
</person>

Fields having "N/A" as value should instead simply be omitted in XML.

We did notice in the document it says "Note: You MUST NOT put email addresses in the authors field of an IANA Registration."
I would prefer a "Registrant" and a "Registrant E-mail".  Then a separate "Specification" where it points to the document and that is where a person could get the contact info for the authors.
What are your thoughts on that?  Is it possible to have the document reflect those?

Thanks,

Michelle Cotton
IANA

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

---

From: "Alexander Mayrhofer" <[email-masked]>
Date: Tue, 21 Oct 2008 11:08:26 +0200

Hello Michelle,

thanks for the suggested XML chunk. Generally, is there any suggestion
on namespace/schema of that XML? i'm well aware that this is right now a
chunk, but defining a namespace would allow to define a schema.

more comments inline.

> <record>

I'd rather suggest to name that "top" element "<enumservice>" - "record"
seems too generic to me.

>   <class>Protocol-based</class>

Fine with me. Those elements could be restricted fairly well in a schema
- type as well as subtype are limited to 32 alpha/digit/dash characters.

class would be a choice of possible values.

>   <scheme>bars</scheme>

I would rather call that "urischeme", but "scheme" is good enough, i
think.

>     addressed by the associated URI in order to foo the bar. [...]

hmm.. the naming of the element somehow would clash with the
"specification reference" listed below. maybe rename that to
"functionalspec" to make it clear?

[see below for the "further info" element on content issue..]

>   <security>See <xref type="rfc" data="rfc9999"/>, Section 

fine with me.

>   <usage>COMMON</usage>

Fine, would be easy to restrict it to the allowed values

>   <xref type="rfc" data="rfc9999"/>

I think that the reference to the specification deserves to be
highlighted, i would suggest using something like the "security" element
outlined above, for example:

<specdoc>See <xref ...> </specdoc>

BTW, how would one reference documents of other SDOs? like in XML2RFC
templates?

>   <xref type="person" data="Jane_Dale"/>

Fine with me - my question is what the relation between person objects
and enumservices would be - would the person be a seperate object, or
simple embedded in the Enumservice registration XML document?

>   <info>Further information free text...</info>

There is an issue here, wich also applies to the "spec" element above -
we have Enumservices registrations which use "markup" in those fields -
bullet lists, paragraphs, etc.

If we just allow plaintext here (which would be the simplest version) we
would lose existing information.

However, personally i think that such information should rather be
contained in the registration document itself rather than the registry
entry - 

> We did notice in the document it says "Note: You MUST NOT put 
> email addresses in the authors field of an IANA Registration."
> I would prefer a "Registrant" and a "Registrant E-mail".  
> Then a separate "Specification" where it points to the 
> document and that is where a person could get the contact 
> info for the authors.

I *think* the idea of not allowing an email address in the "author"
field was that this information was supposed to be taken from the
specification document's "authors" section. 

I'm happy to include the "person" information that you have outlined
above, especially if there are other registries that make use of that
scheme as well.

Any comments?

Alex