Subject: Re: [IPTEL] corrections to CPLv2 DTD and some text

From: Jonathan Lennox <[email-masked]>
Date: Fri, 7 Jul 2000 18:19:27 -0400 (EDT)

My *profound* apologies for taking so long to get back to this.  I've been
swamped.

On Tue, May 2 2000, "Nilo Mitra" wrote to "[email-masked]', [email-masked]', [email-masked]'" saying:

> Here are some corrections to the DTD of the CPL version 2 document,
> draft-ietf-iptel-cpl-01.txt, dated March 10, 2000.

Wonderful -- thank you.  I'm working on the next revision of the document.
(More general CPL comments will follow in a later message.) 

> I am working on the assumption that the text takes precedence over the DTD,
> and therefore I have corrected the CPLv2 DTD to conform to the intent stated
> in the text. I do realise that the CPL DTD is not sufficient for a cpl
> script's validity but feel that it should accurately reflect the text as far
> as is possible. Think of my efforts as making corrections to the CPL DTD
> syntax using DTD and XML rules to allow for greater expressivity (if that's
> a word).

This is true; however, it may be that the text was unclear in some
sections.

> 1. The preamble <?xml version="1.0"...?> is not needed, as a DTD is not an
> XML document.

Not a standalone document, anyway, I presume you mean?

> 2. Enclose the whole thing within: 
> 	<! DOCTYPE cpl [
> 	....
> 	]> 

The W3C's DTDs (e.g. <http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd>)
don't do this.  Is it really necessary/appropriate?

> 3. Is it really intended that the timezone information can be included more
> than once, as described by the asterisk (0 or more) in the definition of the
> top level element
> namely <!ELEMENT cpl (timezone*, subaction*, outgoing?, incoming? )> ?
> 
> I suspect it should be 0 or 1 in which case a "?" should be used to qualify
> it so that it reads <!ELEMENT cpl (timezone?, subaction*, outgoing?,
> incoming? )>.

It *is* possible (though perhaps not terribly likely) that someone would
want to be able to say "do such-and-such between 9 am and 5 pm Eastern Time,
and such-and-such between 8 pm and 9 pm Pacific Time".  This could actually
be useful if you're specifying rules in timezones with different DST rules;
otherwise it's just a notational convenience.  I see no reason not to
support it, though.

> 4.  It would be good to write the top level element as 
> 	<!ELEMENT cpl ( (%Ancillary;)*, subaction*, outgoing?, incoming? )>
> thereby not requiring any change to the top level structure when there are
> additional items added to the ancillary information beyond the currently
> supported "timezone".

Good idea.  Though presumably it should either be "%Ancillary;" or
"(%Ancillary;)?" depending on how the Ancillary entity is written.

> 5. The address-switch node or element as currently written, namely
> 	<!ELEMENT address-switch ( (address | not-present)+, otherwise? )>
> would suggest that the not-present element can potentially be present
> multiple times. This element definition should be rewritten as
> 	<!ELEMENT address-switch (address+, not-present?, otherwise? )>

It doesn't make sense to have not-present occur multiple times, but it could
potentially (I think) make sense for some address tags to occur after the
not-present tag, since order is significant in switches.  Unfortunately,
the DTD regex syntax for element tags can't express this concisely.  I
suppose it could be:

<!ELEMENT address-switch (address*, not-present?, address*, otherwise? )>

but that's awfully ugly, and leads to exponential explosion if we add more
occurs-anywhere-but-only-once tags.  My thought was to just throw all the
tags which can occur anywhere into a fixed bag, and describe the only-once
properties in the text.

Note that my I *will* change address-switch from 1-or-more address tags to
0-or-more, because <address-switch> <not-present /> <otherwise />
</address-switch> is sensible.

> 6.  The attribute list for <address> should contain only one of "is",
> "subdomain-of" or "contains", but this limitation is not perfectly expressed
> in the syntax

I don't think you can use alternation in ATTLISTs; from my reading of
section 3.3 of the XML spec, an ATTLIST only consists of a list of AttDefs,
with no other structure to them.

[Comments 7 and 8 elided; they carry over 5 and 6 naturally to
string-switch, and my same comments apply.]

[First half of Comment 9 elided, similarly]
> As the text says that the not-present output is never true for a
> time-switch, why not leave it out altogether from the definition of the DTD
> so that it becomes
> 	<!ELEMENT time-switch (time+, otherwise? )>

I put it in so that the handling of switches could be more generic.  I
don't feel too strongly about this one way or the other, though.

> 10. A propos the <time> element and its attributes, looking at the various
> examples given, it seems to imply that the absence of some elements implies
> a default value, for instance:
> 	timeofday absent => all day
> 	year absent => all year
> 	day absent => all week (btw, is it "weekday" as stated in fig 6 or
> is it "day" as in the rest of the section?)
> 	month absent => every month

Yes, this is what I had in mind; I think it's implicit in my "and-of-ors"
formulation, but I'll say it explicitly.

However, I don't think specifically allowing "all year" as a value for the
year attribute (etc.) is a good idea; parsing the time-switch is hard enough
already.  I'd rather just leave the absence of an attribute as meaning "any
value".

Alternately, for the default values we could have something like

 	<!ATTLIST time
 		year		CDATA	"0-9999"
 		month		CDATA	"1-12"
 		date		CDATA	"1-31"
 		day		CDATA	"0-6"
 		timeofday 	CDATA 	"0000-2359"

but I don't think this gains anything, and the specification of the year
range is a bit forced.
 
> 12. Only one of the attributes of <priority> may be present. This fact is
> not currently expressed correctly in the current cpl DTD (just as in item 6
> above), but there is one additional complexity. One way to express this is:
> 
> <!ATTLIST priority (less %PriorityVal; | greater %PriorityVal; | equal CDATA
> #IMPLIED) #REQUIRED>
> 	
> The CPLv2 draft text seems to imply that one of these must be present, hence
> the #REQUIRED.

Same problem as above -- alternation only applies to ELEMENT, not ATTLIST.
Yes, if there were a way to say "exactly one of three" I would, but there
isn't.

> 13. A comparison of the text and the attribute list for <proxy> in the DTD
> suggests that there needs to be a clarification of the words "optional", and
> having a dfault value. The attribute list
> 	<!ATTLIST proxy
> 	...
> 	recurse	(yes|no) "yes"
> 	...
> 	>
> means that the attribute recurse is not really absent, even if it is not
> actually written down. It's textual absence implies its presence with the
> value "yes". And the same for the other attribute with a default value.

It's the same question as for the time-switch, though I chose the opposite
solution here.  Is it better for defaults to be specified syntactially (in
the DTD) or semantically?

> 14. As the values for the status attribute in <reject> have been specified
> in the text, the DTD should provide the enumerated list (where I have added
> an additional value "other" as a catch all for the SIP-specific reject codes
> 4xx, 5xx, 6xx). Thus,
> 	<!ATTLIST reject
> 	status	(busy | notfound | reject | error | other) #REQUIRED
> 	reason	CDATA #IMPLIED
> 	>
> 
> or, if one wised to expose the SIP-specific codes themselves, one could
> write
> 
> 	<!ENTITY % SIP-reject-code '(4xx | 5xx | 6xx)' >
> 
> 	<!ATTLIST reject
> 	status	(busy | notfound | reject | error | %SIP-reject-code;)
> #REQUIRED
> 	reason	CDATA #IMPLIED
> 	>

The problem is that DTD parsers are obnoxiously literal.  If you say that it
can be "5xx", it will only allow "5xx", not "503" as we want.  And I don't
want to list out all 300 possible 4xx, 5xx, and 6xx SIP status codes in the
DTD.  So making the tag CDATA seemed the best solution.  I'll add text
explaining this.

> 15. The output of a log node can be any node; so it should be <!ELEMENT log
> ( %node; ) > rather than have child nodes as currently shown (which was in
> version 1).

Yes.

> 
> MISCELLANEOUS
> 
> 1. Figure 1. Shouldn't "subaddress-of" be "subdomain-of"?

Yes, fixed.

> 2. In section 4.1 and figure 6 the use of 'weekday" or 'day" should be
> clarified.

Unified to "day", which it was everywhere but the figure.

> 3. In section 5.1 and Figure 8, shouldn't something be said about the
> attribute 'clear"?

Yes.  Added.

> 4. In Figure 11, the name of the node should be "proxy".

Fixed (copy and paste error).

> 5. The text accompanying the description of the <time> element in section
> 4.3 does not make clear if at least one of the attributes (year, month,
> date,...) must be present.

While I don't know that it would be *sensible* to have a <time> node with no
attributes, it seems like forbidding it would just mean additional
complexity for server authors.  Its meaning is unambiguous -- "all the
time."

> That's all for now

Thanks a lot.

-- 
Jonathan Lennox
[email-masked]

_______________________________________________
IPTEL mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/iptel

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sat, 08 Jul 2000 00:20:15 -0400

> don't feel too strongly about this one way or the other, though.

I'd prefer it would be there. Keeping it generic means I can define an
abstract class for all switches which includes handling of otherwise and
not-present.

> the DTD) or semantically?

My preference is semantically, since the default may be based on some
logic that is more complex than can be expressed as a simple value.

> complexity for server authors.  Its meaning is unambiguous -- "all the

I agree. Lets allow it to have no values.

-Jonathan R.

-- 
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com

---

From: James Undery <[email-masked]>
Date: Mon, 10 Jul 2000 10:03:47 +0100

> </address-switch> is sensible.

My uglier suggestion would be

<!ELEMENT address-switch ( (address+, otherwise?) | (address*, not-present, otherwise?) ) >

similarly I'd change string-switch, time-switch and priority-switch

<!ELEMENT string-switch ( (string+, otherwise?) | (string*, not-present, otherwise?) ) >
<!ELEMENT time-switch ( (time+, otherwise?) | (time*, not-present, otherwise?) ) >
<!ELEMENT priority-switch ( (priority+, otherwise?) | (priority*, not-present, otherwise?) ) >

> don't feel too strongly about this one way or the other, though.

I'd agree with Jonathan in his reply to this mail. Leave it in.

> Yes, if there were a way to say "exactly one of three" I would, but there

I am not sure I'd recommend it, but, switching from attributes to elements would make this possible although very ugly. Unfortunately DTD don't
provide a very good description of scripting languages as they are more concerned with structure of elements rather than attributes as you pointed
out.

> > MISCELLANEOUS

Figure 2 The proxy tag should have timeout="10" to match figure 1

Section 9 Why is the abbr mandatory? I don't have a problem with this really but it seems a bit unnecessary.

Figure 21 an 25 The proxy timeout="8s" shouldn't this be "8" or the options for units and their post fixes described.

Figure 21 A real guess but is the busy tag missing an output node?

Figure 24 The semi-colon in the mailto URI should be a "?" I think.

Finally and I apologise in advance,  the mathematician in me when into spasm whilst reading about the ordering of location sets (section 6.1), I
think location lists would be a more appropriate term.

James Undery

---

From: Jonathan Lennox <[email-masked]>
Date: Fri, 7 Jul 2000 17:29:40 -0400 (EDT)

<!ATTLIST time
 		year		CDATA	"0-9999"
 		month		CDATA	"1-12"
 		date		CDATA	"1-31"
 		day		CDATA	"0-6"

Yes.

Yes, fixed.

Yes.  Added.

Thanks a lot.

-- 
Jonathan Lennox
[email-masked]