Subject: RE: Service Message Format

From: "Gould, James" <[email-masked]>
Date: Mon, 22 Jul 2002 13:39:17 -0400

Scott,

I believe the <msg> element is fine the way it is, since it is contained
within an EPP response which is already extensible (i.e. <transfer> query
response for transfer messages).  The <msg> element provides the contextual
information related to the message, which can be plain text, and the type of
response contains the data. By making the <msg> a holder for message
specific content, it would duplicate the use of the EPP response extensions.

Jim

> ----------
> From: 	Hollenbeck, Scott
> Sent: 	Monday, July 22, 2002 1:08 PM
> To: 	[email-masked]'
> Subject: 	Service Message Format
> 
> Something Hong mentioned in one of his recent notes got me thinking about
> service messages (the kind that can be retrieved using the <poll> command)
> and how their format is currently (un)specified.  The current specs use
> the
> XML Schema "normalizedString" type for the <msg> element; this allows for
> text messages, but no additional XML.  I was wondering if folks might find
> it useful to allow XML in the <msg> element so that it would be possible
> for
> a server operator to define parsable message structures.
> 
> -Scott- 
> 
>

---

From: "Liu, Hong" <[email-masked]>
Date: Mon, 22 Jul 2002 12:44:20 -0500

Scott,

I think this is in the right direction to resolving the notification
problem. I am for it. Thanks!

--Hong

-----Original Message-----
From: Hollenbeck, Scott [mailto:[email-masked]]
Sent: Monday, July 22, 2002 1:08 PM
To: [email-masked]'
Subject: Service Message Format

Something Hong mentioned in one of his recent notes got me thinking about
service messages (the kind that can be retrieved using the <poll> command)
and how their format is currently (un)specified.  The current specs use the
XML Schema "normalizedString" type for the <msg> element; this allows for
text messages, but no additional XML.  I was wondering if folks might find
it useful to allow XML in the <msg> element so that it would be possible for
a server operator to define parsable message structures.

-Scott-

---

From: "Gould, James" <[email-masked]>
Date: Mon, 22 Jul 2002 18:09:52 -0400

I further discussed this issue with Scott, and I don't see an issue with
allowing for mixed XML in the <msg> element.  This allows for the current
behavior of the use of plain text messages, does not require a new extension
mechanism, and provides additional flexibility in the poll messages.  This
assumes that the <msg> element contains well-formed XML that is not
validated.

Jim

> ----------
> From: 	Gould, James
> Sent: 	Monday, July 22, 2002 1:39 PM
> To: 	[email-masked]'; Hollenbeck, Scott
> Subject: 	RE: Service Message Format
> 
> Scott,
>

---

From: janusz sienkiewicz <[email-masked]>
Date: Wed, 24 Jul 2002 13:19:09 -0400

This message is related to <msg> element in Poll command (adding XML to <msg> element).

I think one thing seems to be forgotten in the discussion. <msg> element is a child element for both <result> and <msgQ>
elements. I think the change proposal should be more specific. It should describe proposed behaviour of <msg> element in both <msgQ> and <result> cases.

If we allow XML for '<result><msg>' for some epp implementations it can be quite a significant change. It may affect all command responses.

Janusz Sienkiewicz

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Wed, 24 Jul 2002 13:50:49 -0400

> If we allow XML for '<result><msg>' for some epp implementations it
> can be quite a significant change. It may affect all command responses.

Indeed, and that's why it's not part of the proposal -- we're only talking
about service messages that may be retrieved via the <poll> command.  You
correctly noticed that the current schema uses the same data type for both
<msg> elements; that will have to change.  I was planning on creating a new
type to allow the use of mixed content only within the service message <msg>
element.

-Scott-