RE: I-D on Uniform Treatment of Pending Action Notification in EPP

["Hollenbeck, Scott" <shollenbeck@verisign.com>]

>  http://epp-ver-04.sourceforge.net/IETF/draft-liu-epp-pa-notify-00.txt

[snip]

> This is a strawman proposal intended to summarize the recent 
> discussions on
> related topics and to bring more focused discussion to bring 
> this issue to a
> conlusion. Your comments are greatly appreciated.

I like the way the document explores the issues of service message
notification, and it provides rational arguments (except for one*) to
explain why a service message convention might be useful.  I do have two
specific concerns:

- * Statements like "current EPP core specifications do not address the
notification messaging in a generic way" are incorrect and misleading.  If
anything, the current <msg> element is _too_ generic -- there are no
specific formatting "rules" for what constitutes a service message.  That's
about as generic as things can get.  This sort of statement would be
accurate if reworded to something like "to provide maximum flexibility for
server operators, current EPP core specifications do not define specific
service message formats".

- The proposed <paNotify> element doesn't have to be added to the core
schema at all.  Everything that's being suggested can be done within the
current (well, the soon-to-be-modified) <msg> element.  To hack Hong's
example a bit, here's how what's being proposed can be done within the scope
of the changes we've already talked about on the list:

  S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
  S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
  S:     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  S:     xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
  S:     epp-1.0.xsd">
  S:  <response>
  S:    <result code="1301">
  S:      <msg>Command completed successfully; ack to dequeue</msg>
  S:    </result>
  S:    <msgQ count="5" id="12345">
  S:      <qDate>2000-06-08T22:00:00.0Z</qDate>
  S:      <msg>Pending action completed successfully.
  S:        <paNotify paResult="1">
  S:          <paTRID>54321-XYZ</paTRID>
  S:        </paNotify>
  S:      </msg>
  S:    </msgQ>
  S:    <trID>
  S:      <clTRID>BCD-23456</clTRID>
  S:      <svTRID>65432-WXY</svTRID>
  S:    </trID>
  S:  </response>
  S:</epp>

Note how the <paNotify> element can be carried in the <msg> element.  No
fuss, no muss.  Here's what the changed <msg> element data type is going to
look like to support mixed content:

  <complexType name="mixedMsgType" mixed="true">
    <sequence>
      <any processContents="skip"
       minOccurs="0" maxOccurs="unbounded"/>
    </sequence>
    <attribute name="lang" type="language" default="en"/>
  </complexType>

The 'processContents="skip"' attribute tells the parser to skip schema
validation for any XML found within the element, which means that validation
(if needed) should be done in a software layer that consumes the message and
we have complete flexibility in describing service message formats.

One might argue that the content of the <msg> element _should_ be
schema-specified and validatable.  This could be accomplished by changing
the value of processContents to either "lax" (validate the content if at all
possible, but don't choke if it can't) or "strict" (validate the content).
I might be convinced to go with "lax", but "strict" causes the same concerns
for me about being too restrictive in what an operator can put in a service
message.

I'm not trying to put the kibosh on this idea.  If anything, I think it's a
_good_ idea to get some operator agreement on the format of service messages
used in specific operating environments.  My objection is that the format
should NOT be part of the core schema because what fits in one environment
may be constraining in another, and I truly believe that the core schema
should be generic in this regard.

Since Hong hasn't yet seen all of the changes that are going into the core
schema I can understand how we might not be in synch.  If this document were
positioned as a suggestion for an informational "implementers agreement"
(with the modifications I've suggested above), I'd support it 100%.  I can
not support adding another element to the core schema to carry service
message information when there's already an element present for that
purpose.

-Scott-