> > * Section numbers would make it much easier to reference parts
> > of the spec
Probably true. We will see if we can work this in.
> >
> > * You're mixing protocol information and perl API information
> > in the same document, and even within the same section. That
> > means that the first time my PHP (or Java, ASP, etc. client
> > has trouble, I still need to look at the perl source to see
> > what you *really* do.
It's true that the document is a bit of a hybrid. Initially the document was
written as a Perl API document, and then we generalized it to serve as a
generic protocol document. In doing so, we've left examples in Perl. And in
many places we have given explanations in Perl, because it would be
difficult to describe the protocol without using some language as a
reference point.
I'm not sure I understand the point about having to look at the perl source
to see "what we really do". What we really do is described accurately in the
document. If not, please let us know where you feel it is not
accurate/descriptive.
In any case, it would seem like standard procedure that anyone who wanted to
write a non-perl implementation would study the perl implementation to some
extent. I'm not suggesting that this is necessary, but realistically it's
probably what a developer would do, just to be sure they understood things
correctly.
> >
> > * <pre> tags around the code examples would make it easier to
> > read the examples.
This will be corrected.
> >
> > * is the 64-char limit on strings defined by the protocol, or
> > just a limitation of the perl client?
The 64 char limit is on certain contact fields. The limit is imposed by our
database design. i.e. we only accept a max of 64 characters for various
contact info fields. Not sure why this is. It may be that NSI only accepted
64 characters so that's what we used in our design. We will investigate.
> >
> > * BNF (or regex's) of acceptable input for fields would be
> > helpful
Possibly. While I don't discount the usefulness of defining the input field
syntax there are two issues:
1) we would need a month just to properly investigate and document it.
2) not sure it is that useful because most fields are straightforward
alphanumeric fields, with the exception of domains names and nameserver
names and IP addresses which require a specific "dotted" syntax.
> >
> > * <META NAME="Generator" CONTENT="Microsoft Word 97"> -- This
> > may be why the major section heading are actually *smaller*
> > than the minor headings in my brower (NS4.51). Makes it
> > difficult to follow the flow.
We will correct this.
Thanks for your feedback!
Regards,
sA
Scott Allan
Director OpenSRS
[EMAIL PROTECTED]
