RE: Service Message Format

["Gould, James" <JGould@verisign.com>]

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: 	'ietf-provreg@cafax.se'; Hollenbeck, Scott
> Subject: 	RE: Service Message Format
> 
> 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: 	'ietf-provreg@cafax.se'
> > 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- 
> > 
> > 
> 
>