DTDs in CPIM-03 (was RE: draft-ietf-impp-cpim-03)

Moving right along...

Yes, Scott, I believe this was what I was thinking of. Though I'm curious -
does your draft make any recommendation about using DTDs vs. XML Schemas? I
remember from somewhere that the Apps ADs had expressed a preference for XML
Schemas over DTDs. I note that from a consistency perspective the PIDF draft
uses XML Schemas rather than DTDs.

In any event, how the abstract protocol syntax is characterized is only part
of the issue with the DTDs in cpim-03. I am more broadly concerned about the
usage of an abstract protcol syntax here. While it might be handy for those
trying to understand the CPIM model, it is also apparently the source of
some confusion. The recent issue about the 'subscription ID' vs. transID in
cpim-03 is a good example - to what degree does the abstract syntax provide
requirements for CPIM-based protocols? Could the abstract syntax for the
subscription operation, for example, require that there must be separate
transaction IDs and subscription IDs in APEX and SIMPLE? The abstract syntax
takes up a considerable amount of space in the draft to provide an unusable
strawman protocol for the sake of... populating the examples? I suspect that
any necessary operations or elements in CPIM-based protocols could be
quickly sketched without the need for a DTD (let alone 4 DTDs).

Does anyone feel that these DTDs (and the abstract protocol) are useful in
cpim-03, or that they have any obvious advantages over having a paragraph
that explains something like "Subscriptions contain a PRES URI identifying
the target and the following other elements blah blah".

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Hollenbeck, Scott [mailto:[email protected]]
> Sent: Friday, August 16, 2002 8:36 AM
> To: 'Peterson, Jon'; [email protected]
> Subject: RE: draft-ietf-impp-cpim-03
> 
> 
> > - I think the purpose of the DTDs (sections 6, 7, 8 and 9) in 
> > the draft is a
> > little obscure, and that they could use some more 
> > motivation/explanation if
> > they are to remain. Should some or all of these be provided 
> > elsewhere (in
> > MSGFMT or PIDF)? Process-wise, I also seem to recall hearing 
> > that placing
> > DTDs in RFCs was now discouraged...
> 
> Jon, this might be the source of your DTD-discouraging recollection:
> 
> http://www.ietf.org/internet-drafts/draft-hollenbeck-ietf-xml-
guidelines-05.
txt

(sorry if the URL gets line-wrapped)

Section 4.7 in particular.  It might be more accurate to say that DTD use is
being discouraged if there are rigorous validity or extensibility
requirements to be met, but ultimately the choice of a specification format
is something that should be considered carefully by a protocol designer.

-Scott-



  [reminder: [email protected] for non-technical discussions, please]



  [reminder: [email protected] for non-technical discussions, please]