[Data-modeling] RFCs that define a protocol

Tue Apr 28 18:02:14 UTC 2009

I've followed this list for quite a while more from interest in the topic than from any expectation that I might be able to provide a contribution. It is nice now to see an area where I might be able to provide something useful.

Answering the specific questions below.

First the scope of things RFC's cover is wider than what can properly be called Internet protocols, though they generally are related to areas where two different computer systems need to be able to interoperate. An example of what I mean here can be seen in documents like RFC2279 which defines UTF-8 character encoding or the various RFC's that define different MIME application types. These are certainly important for the Internet but are not specifically Internet Protocols as much as just interoperability protocols. Others like DHCP are required for interoperability within a network but not across the internet. Then there are some that are sort of meta-RFCs in that they define things about the RFC process like RFC 2119 which defines standard terms for levels of requirements in RFCs (e.g. what exactly does it mean in an RFC when they say I MUST do something vs. SHOULD) and RFC 5234 which defines the format for specifying a data syntax (called ABNF or Augmented Bachus-Naur format).

With regards to "Obsoleted by" and "Supercedes". I would suggest care here simply because a single RFC can obsolete more than one other RFC and RFC's can be repeatedly obsoleted as generations of a protocol evolve. RFC's can also update other RFC's which essentially means it obsoletes some part of the other RFC (for an example see here http://www.faqs.org/rfcs/rfc2821.html)

> 2. There should be a new type to model RFCs, and I'm 
> considering the following properties:
> - Status (informational|experimental|...)
> - Date published (/type/datetime)

> - Published by (/people/person)

If you're talking about RFC's "Published by" is redundant RFCs are documents published by the IETF, if you mean Internet standards more widely including things like W3C standards then the scope of this work will increase somewhat and you should probably leave published by and add

     - Document type

> - Obsoleted by (rfc)
> - Specifies protocol (internet protocol)
I would also add

     - Title

     - Authors 

     - Working Group (the group responsible for the document, despite having an explicit Author, many RFCs are the product of working group discussions)

     - Standard number (when things become a "Standard" that has passed through the entire RFC acceptance process it is assigned a Standard number in addition to its RFC number, for example RFC 821 is STD0010)

>3. Should RFCs be assigned keys that correspond to their 
 > serial numbers? We could then easily generate 
 > URL-template-based links to RFCs themselves, assuming the 
 > IETF URLs are regular.
That would work well for published standards but not so well for things that are in process. For example during the process of getting to a final standard you will often have a -bis version of a document (e.g. 2821 was followed by 2821-bis). Similarly there will also often be related documents that will eventually become part of the standard but are published in a seperate Errata document. I'm not sure if you would need ot account for those. 

Tying this to the existing Internet Protocol type might be a challenge since not al of the protocols listed are defined by an RFC (e.g. I'm pretty sure there's no JSON RFC).

Sorry for the long rambling answer . Hope I answered enough of your questions in a way that is at least somewhat useful

> > -----Original Message-----
> > From: data-modeling-bounces at freebase.com 
> > [mailto:data-modeling-bounces at freebase.com] On Behalf Of Vishal Talwar
> > Sent: Monday, April 27, 2009 4:06 PM
> > To: data-modeling
> > Subject: [Data-modeling] RFCs that define a protocol
> > 
> > There is an open request for adding an "RFCs that define this 
> > protocol" property to the Internet Protocol type. Since I 
> > know almost nothing about the subject matter, I'd like to 
> > open this up for input from everyone here. Specifically,
> > 
> > 1. Should this property be limited to the Internet Protocol 
> > type, or can RFCs define other types of protocols?
> > 
> > 2. There should be a new type to model RFCs, and I'm 
> > considering the following properties:
> > - Status (informational|experimental|...)
> > - Date published (/type/datetime)
> > - Published by (/people/person)
> > - Obsoleted by (rfc)
> > - Specifies protocol (internet protocol)
> > 
> > Am I missing anything?
> > 
> > 3. Should RFCs be assigned keys that correspond to their 
> > serial numbers? We could then easily generate 
> > URL-template-based links to RFCs themselves, assuming the 
> > IETF URLs are regular.
> > 
> > The original discussion took place here:
> > http://www.freebase.com/discuss/threads/guid/9202a8c04000641f8
> > 000000009f237f8?domain=/computer
> > 
> > Thanks!
> > Vishal
> > _______________________________________________
> > Data-modeling mailing list
> > Data-modeling at freebase.com
> > http://lists.freebase.com/mailman/listinfo/data-modeling
> > 
> 
> _______________________________________________
> Data-modeling mailing list
> Data-modeling at freebase.com
> http://lists.freebase.com/mailman/listinfo/data-modeling

_________________________________________________________________
Windows Live™ Hotmail®:…more than just e-mail.
http://windowslive.com/online/hotmail?ocid=TXT_TAGLM_WL_HM_more_042009
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freebase.com/pipermail/data-modeling/attachments/20090428/8c25ab3e/attachment-0001.htm 