Subject: Re: [siprec] extensionData in XML

From: "Jain, Rajnish" <[email-masked]>
Date: Fri, 1 Apr 2011 09:11:08 -0400

There may be such motivation from how the CSTA standards are specified. They have an element called privateData for each message. It is a placeholder for any non-standardized extensions. This could be legacy and may not mean much for the modern text based protocols.

That said, I think you're right (this generally applies to any text based protocols and is the fundamental basis for forward/backward compatibility in such protocols).

Raj

-----------------------------------------------------
Please consider the environment before printing this email.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Hadriel Kaplan
> Sent: Thursday, March 31, 2011 8:43 PM
> To: [email-masked]
> Subject: [siprec] extensionData in XML
>
> Howdy,
> With regards to the extensionData concept and XML, I have a few basic
> questions.  I am by no means an XML expert so it could just be my lack
> of knowledge which makes me confused.  If so, just tell me to RTFM.
>
> draft-ram-siprec-metadata-04 says in section 4.6:
>    A recording metadata object contains additional data not specified
> as
>    part of siprec.  This is intended to accommodate future standards
>    track extensions, as well as vendor and user specific extensions.
>    The mechanism MUST provide a means of unambiguously distinguishing
>    such extension data.
>
> What confuses me is I didn't think XML had to do such machinations to
> accommodate this need.  I thought we could just specify in our RFCs
> that unknown XML elements and attributes MUST be ignored, so that
> future RFCs could add them without having to leave specific "blob" XML
> elements to carry such data.  Or at least that's what we've done so far
> in SIP RFCs with XML bodies, afaik.  I also thought XML had a namespace
> model that could be used to disambiguate proprietary elements from
> standard ones.  If both of those theories are correct, why do we need
> to define an extensionData element?
>
> -hadriel
>
> _______________________________________________
> siprec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/siprec

DISCLAIMER: This e-mail may contain information that is confidential, privileged or otherwise protected from disclosure. If you are not an intended recipient of this e-mail, do not duplicate or redistribute it by any means. Please delete it and any attachments and notify the sender that you have received it in error. Unintended recipients are prohibited from taking action on the basis of information in this e-mail.E-mail messages may contain computer viruses or other defects, may not be accurately replicated on other systems, or may be intercepted, deleted or interfered with without the knowledge of the sender or the intended recipient. If you are not comfortable with the risks associated with e-mail messages, you may decide not to use e-mail to communicate with IPC. IPC reserves the right, to the extent and under circumstances permitted by applicable law, to retain, monitor and intercept e-mail messages to and from its systems.

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Fri, 1 Apr 2011 20:07:58 +0530

Hadriel/Raj,

Extensiondata XML is provided as per Metadata model extensiondata block.
During the initial discussion of metadata model draft, we realized that
lot of attributes specified for recording are call center specific or
specific domain related and it is outside the scope of IETF SIPREC but
it is required for those specific solution to work. Extensiondata XML
element helps to meet those requirement.

Extensiondata is provided with URN UUID to pass or not pass
independently in partial data. But it is open item whether extensiondata
has to be within specific metadatablock or not.

Please read inline for more comments.

Thanks
Partha

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Jain, Rajnish
Sent: Friday, April 01, 2011 6:41 PM
To: Hadriel Kaplan; [email-masked]
Subject: Re: [siprec] extensionData in XML

There may be such motivation from how the CSTA standards are specified.
They have an element called privateData for each message. It is a
placeholder for any non-standardized extensions. This could be legacy
and may not mean much for the modern text based protocols.

<partha> I really didn't get the reason why is it not require for modern
text based protocols. This is more like generic param in SIP or xs:any
in XML. RFC 6120 is a new RFC which has the similar usage.
</partha>

That said, I think you're right (this generally applies to any text
based protocols and is the fundamental basis for forward/backward
compatibility in such protocols).

Raj

> elements to carry such data.  Or at least that's what we've done so 
> far in SIP RFCs with XML bodies, afaik.  
> namespace model that could be used to disambiguate proprietary 
> elements from standard ones.  If both of those theories are correct, 
> why do we need to define an extensionData element?
>
> -hadriel
>

DISCLAIMER: This e-mail may contain information that is confidential,
privileged or otherwise protected from disclosure. If you are not an
intended recipient of this e-mail, do not duplicate or redistribute it
by any means. Please delete it and any attachments and notify the sender
that you have received it in error. Unintended recipients are prohibited
from taking action on the basis of information in this e-mail.E-mail
messages may contain computer viruses or other defects, may not be
accurately replicated on other systems, or may be intercepted, deleted
or interfered with without the knowledge of the sender or the intended
recipient. If you are not comfortable with the risks associated with
e-mail messages, you may decide not to use e-mail to communicate with
IPC. IPC reserves the right, to the extent and under circumstances
permitted by applicable law, to retain, monitor and intercept e-mail
messages to and from its systems.
_______________________________________________
siprec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/siprec

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 2 Apr 2011 08:49:06 -0400

Hi Partha,
I think you're missing my point (or I'm missing yours) - you can do all of that without specifying an "extensionData" XML element.  Unknown XML elements are simply ignored by the other side, so Cisco can add a "ciscoPrivateData" XML element wherever it wants and send it to an Acme; and that private element will be ignored by Acme while everything else will continue to work.  Which I think is the behavior you want, right?

-hadriel

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Mon, 4 Apr 2011 00:15:49 +0530

Hadriel,
 
I guess we have common understaning to the extend that the intention is to send some extensiondata (Unknown) attribute by SRC which may or may not understand by SRS and also for the usage of xs:any as the solution.  Few stuff are missing in yours proposal w.r.t partial data passing of extensiondata:
 
The question is whether there is a need to pass the extension data during every time the corresponding metadata block is passed or updated. For example, CS metadata block sends extension data specific to call center data like Agent is remote or local, agent or customer initiated call (direction) during the CS block creation (INVITE) and these constant information in extensiondata is not required to be passed in each update of CS metadata like adding video stream in the mid-session.
 
The current model allows to pass extensiondata only during the initial CS block creation and there is no need to update or resend while CS block is getting updated with other CS information. IMO, The current extensiondata mechanism is required as SIPREC puts lot of call centre specific attributes proposed during metadata model draft review as outside the scope of SIPREC and most of the attributes mentioned are constant within the scope of session. 
 
Also, it is possible to pass update only extension data within RS session without impacting parent element. Please let me know your and others opinion whethter it is fine to continue with the current extension-data element or to move xs:any element to each of the metadata block.
 
Thanks
Partha
________________________________

From: Hadriel Kaplan [mailto:[email-masked]]
Sent: Sat 4/2/2011 6:19 PM
To: Parthasarathi R (partr)
Cc: Jain, Rajnish; [email-masked]
Subject: Re: [siprec] extensionData in XML

Hi Partha,

-hadriel

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 6 Apr 2011 10:32:16 +0200

I already posted on this topic on the other thread. Partha states below an additional motivation for handling extension data in the way specified in the current I-D. My counter argument is that anyone specifying particular extension data could specify the expected behaviour when extension data is present in an object and then absent when that object is updated. For some types of metadata it could be that absence means it no longer applies, and for other types of metadata it could be that absence means it has not changed. The latter approach would avoid the need for repeating large quantities of metadata each time there is a minor change to an object.

John (as individual)

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Parthasarathi R (partr)
> Sent: 03 April 2011 19:46
> To: Hadriel Kaplan
> Cc: [email-masked]; Jain, Rajnish
> I guess we have common understaning to the extend that the 
> intention is to send some extensiondata (Unknown) attribute 
> by SRC which may or may not understand by SRS and also for 
> the usage of xs:any as the solution.  Few stuff are missing 
> in yours proposal w.r.t partial data passing of extensiondata:
>  
> The question is whether there is a need to pass the extension 
> data during every time the corresponding metadata block is 
> passed or updated. For example, CS metadata block sends 
> extension data specific to call center data like Agent is 
> remote or local, agent or customer initiated call (direction) 
> during the CS block creation (INVITE) and these constant 
> information in extensiondata is not required to be passed in 
> each update of CS metadata like adding video stream in the 
> mid-session.
>  
> The current model allows to pass extensiondata only during 
> the initial CS block creation and there is no need to update 
> or resend while CS block is getting updated with other CS 
> information. IMO, The current extensiondata mechanism is 
> required as SIPREC puts lot of call centre specific 
> attributes proposed during metadata model draft review as 
> outside the scope of SIPREC and most of the attributes 
> mentioned are constant within the scope of session. 
>  
> Also, it is possible to pass update only extension data 
> within RS session without impacting parent element. Please 
> let me know your and others opinion whethter it is fine to 
> continue with the current extension-data element or to move 
> xs:any element to each of the metadata block.
>  
> Thanks
> Partha
> I think you're missing my point (or I'm missing yours) - you 
> can do all of that without specifying an "extensionData" XML 
> element.  Unknown XML elements are simply ignored by the 
> other side, so Cisco can add a "ciscoPrivateData" XML element 
> wherever it wants and send it to an Acme; and that private 
> element will be ignored by Acme while everything else will 
> continue to work.  Which I think is the behavior you want, right?
> 
> -hadriel
> 
> 
> > From: [email-masked] 
> [mailto:[email-masked]] On Behalf
> > Of Jain, Rajnish

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Wed, 6 Apr 2011 14:46:13 +0530

John,

Please read inline

Thanks
Partha 

-----Original Message-----
From: Elwell, John [mailto:[email-masked]] 
Sent: Wednesday, April 06, 2011 2:02 PM
To: Parthasarathi R (partr); Hadriel Kaplan
Cc: [email-masked]; Jain, Rajnish
Subject: RE: [siprec] extensionData in XML

I already posted on this topic on the other thread. Partha states below
an additional motivation for handling extension data in the way
specified in the current I-D. My counter argument is that anyone
specifying particular extension data could specify the expected
behaviour when extension data is present in an object and then absent
when that object is updated. For some types of metadata it could be that
absence means it no longer applies, and for other types of metadata it
could be that absence means it has not changed. 

<partha> Currently, metadata format draft XML element is written with
the basics that "it is no longer applies" in case specific element is
absent in the update. The question is how the information of
extensiondata absence means "it is no longer applies" or "it has not
changed" has to be passed between SRC and SRS. Here, there is a need of
common understanding between SRC and SRS or else the information will be
misunderstand even though both parties understand the specific
extension.

The current extensiondata is taken the route of all other metadata block
XML element definition. There may be better way to represent in
extensiondata XML element apart from creating new metadata block with
URN UUID. I'm including Peter for his advise on XML front. </partha>  

The latter approach would avoid the need for repeating large quantities
of metadata each time there is a minor change to an object.

John (as individual)

> I guess we have common understaning to the extend that the intention 
> is to send some extensiondata (Unknown) attribute by SRC which may or 
> may not understand by SRS and also for the usage of xs:any as the 
> solution.  Few stuff are missing in yours proposal w.r.t partial data 
> passing of extensiondata:
>  
> The question is whether there is a need to pass the extension data 
> during every time the corresponding metadata block is passed or 
> updated. For example, CS metadata block sends extension data specific 
> to call center data like Agent is remote or local, agent or customer 
> initiated call (direction) during the CS block creation (INVITE) and 
> these constant information in extensiondata is not required to be 
> passed in each update of CS metadata like adding video stream in the 
> mid-session.
>  
> The current model allows to pass extensiondata only during the initial

> CS block creation and there is no need to update or resend while CS 
> block is getting updated with other CS information. IMO, The current 
> extensiondata mechanism is required as SIPREC puts lot of call centre 
> specific attributes proposed during metadata model draft review as 
> outside the scope of SIPREC and most of the attributes mentioned are 
> constant within the scope of session.
>  
> Also, it is possible to pass update only extension data within RS 
> session without impacting parent element. Please let me know your and 
> others opinion whethter it is fine to continue with the current 
> extension-data element or to move xs:any element to each of the 
> metadata block.
>  
> Thanks
> Partha
> I think you're missing my point (or I'm missing yours) - you can do 
> all of that without specifying an "extensionData" XML element.  
> Unknown XML elements are simply ignored by the other side, so Cisco 
> can add a "ciscoPrivateData" XML element wherever it wants and send it

> to an Acme; and that private element will be ignored by Acme while 
> everything else will continue to work.  Which I think is the behavior 
> you want, right?
> 
> -hadriel
> 
>

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 6 Apr 2011 14:57:33 +0200

Yes, I would be keen to hear Peter's or other opinions, but one other point. One of the properties of XML is that it is human-readable. Having extension data as a child element of the element representing the object to which it applies seems, in my opinion, to make it more readable. Having extension data as a separate element, with a link to the element to which it applies, seems hard for a human reader, particularly if the link is a long, random string.

John (as individual)

> From: Parthasarathi R (partr) [mailto:[email-masked]] 
> Sent: 06 April 2011 10:16
> To: Elwell, John; Hadriel Kaplan
> Cc: [email-masked]; Jain, Rajnish; Peter Saint-Andre (psaintan)
> intention 
> the initial
> [mailto:[email-masked]] On 
> > >> Behalf Of Hadriel Kaplan

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 06 Apr 2011 17:48:48 -0400

> Yes, I would be keen to hear Peter's or other opinions, but one other point. One of the properties of XML is that it is human-readable. Having extension data as a child element of the element repre…

IMO human readability of the xml is a secondary/tertiary concern.
(SIP is in theory readable, but real sip on the wire tends to be 
difficult to read due to need to match up non-ergonomic numeric 
addresses and tags from one message to another.)

I'm inclined to agree it would be better to embed extensions into the 
basic elements, but not primarily due to readability. IMO extensions 
should function as much like the predefined parts as possible. (Today's 
extension may become common usage tomorrow.)

I just don't know enough xml to define this "correctly".

	Thanks,
	Paul

>> URN UUID. I'm including Peter for his advise on XML front.</partha>
>>

---

From: Dan Burnett <[email-masked]>
Date: Mon, 11 Apr 2011 11:45:17 -0400

As someone who works quite a bit with XML, I'll point out that there  
is an important distinction between data for extensibility and  
expected application-specific data.  As an example of the latter, EMMA  
[1] is an XML format for representing the input of a user (human  
being, commonly) to an automated system, by speech, gesture, pen,  
etc.  Since the way an input is interpreted is dependent upon its  
intended use, there was a need for a designated application-specific  
section to represent the semantics (meaning) of the input.
To make it easier for machine consumers of this format that may be  
seeking the semantics, there is a designated element "interpretation"  
that holds this information.  The contents of this element are  
arbitrary XML in an application-specific XML namespace.

On the other hand, every XML specification I've worked on in W3C has  
needed a way for implementers to innovate via extensions.   
Traditionally this is handled via custom elements and attributes in an  
implementer-specific namespace to avoid name collision with the  
standard elements and attributes.  Since these true innovation  
extensions can occur anywhere, there is no specific XML element  
established in most specifications for "extensions".  Instead, the  
specification defines the expected behavior of a conformant processor  
upon encountering elements and attributes outside of the  
specification's standard namespace.  The nice thing about this  
approach is that allows for innovation in a way that does not cause  
name collision but which could become part of the standard in the  
future (and be moved into the standard's namespace).
For the specifications I worked on, we always required that a  
conformant processor had to do the behavior defined in the  
specification when it received a conformant document but that the  
behavior of the processor when it encountered non-standard elements  
and attributes was at its own discretion -- it could process the  
attributes, ignore them, or report an error, as it deemed appropriate.

So the real question for us here is whether these extension elements  
are *extensions* (which do not require a custom element/location) or  
*expected application-specific information* (which can benefit from  
custom elements and prescribed locations in the XML tree).

-- dan

[1] http://www.w3.org/TR/emma/

On Apr 6, 2011, at 5:48 PM, Paul Kyzivat wrote:

>> Yes, I would be keen to hear Peter's or other opinions, but one  
>> other point. One of the properties of XML is that it is human- 
>> readable. Having extension data as a child element of the element  
>> representing the object to which it applies seems, in my opinion,  
>> to make it more readable. Having extension data as a separate  
>> element, with a link to the element to which it applies, seems hard  
>> for a human reader, particularly if the link is a long, random  
>> string.
>
> I'm inclined to agree it would be better to embed extensions into  
> the basic elements, but not primarily due to readability. IMO  
> extensions should function as much like the predefined parts as  
> possible. (Today's extension may become common usage tomorrow.)
>

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Tue, 19 Apr 2011 16:01:14 +0530

Dan & all,

Sorry for the late reply. Thanks for sharing your XML experience.
<extension-data> tag is provided as extensions to SIPREC metadata. The
current approach allows to ignore the extension-data in case SRS does
not understand. 

I have added few extensiondata as a note of this mail which were
discussed during earlier SIPREC interim meeting. The open question here
is whether the extension-data has to be passed every time (during
partial-update) within metadata XML tag (participant, session) update or
it is enough to send only when extension-data changes. Partial update of
any specific XML elements  needs unique id. RFC 5261 recommends to use
xml:id or type-id as unique attribute. 

The following example illustrate three different mechanism for
extensiondata:

Extensiondata as separate metadata block: (Current format in the draft -
works for partial update, URN UUID is used in all metadata block as of
now)
         <session id="urn:uuid:855a5ded-8420-456d-a70f-6da1eeaeb425"
          group="urn:uuid:efe3930b-2a31-4e6a-a6ab-203fd7078302" />
         </session>
         <extensiondata
id="urn:uuid:a54d6aa5-d40d-43f9-88c5-b4633d873bdd"
          parent="urn:uuid:855a5ded-8420-456d-a70f-6da1eeaeb425">
          <call-center xmlns='urn:ietf:params:xml:ns:callcenter'>
             <supervisor>sip:[email-masked]</supervisor>
           </call-center>
         </extensiondata>

Extensiondata as separate metadata block using xml:id:(Id reduction)
         <session id="urn:uuid:855a5ded-8420-456d-a70f-6da1eeaeb425"
          group="urn:uuid:efe3930b-2a31-4e6a-a6ab-203fd7078302" />
         </session>
         <extensiondata id="extension1"
          parent="urn:uuid:855a5ded-8420-456d-a70f-6da1eeaeb425">
          <call-center xmlns='urn:ietf:params:xml:ns:callcenter'>
             <supervisor>sip:[email-masked]</supervisor>
           </call-center>
         </extensiondata>

Extensiondata as an extension within metadata block: (Ignore the
attribute but needs to be passed in each partial updated)
Example:
         <session id="urn:uuid:855a5ded-8420-456d-a70f-6da1eeaeb425"
          group="urn:uuid:efe3930b-2a31-4e6a-a6ab-203fd7078302" />
           <extensiondata> 
              <call-center xmlns='urn:ietf:params:xml:ns:callcenter'>
                <supervisor>sip:[email-masked]</supervisor>
              </call-center>
           </extensiondata>
         </session>

Please let me know which best suites SIPREC metadata. Including Leon &
Ken explicitly because they provides lot of Extension data attributes
during the discussion of metadata model.

I'm fine with any of the above approach.

Thanks
Partha

Note:
End point information: ip/port, device id (MAC address), DN (used for
the call, in case of multiline). 
Device type: external, station, IVR, routing point, QUEUE, Gateway, MCU,
Operator, etc
Participant Role: caller, called, added, last_redirecting, redirecting,
conferencing, queing, redirected
AgentId, OSLogin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Dan Burnett
Sent: Monday, April 11, 2011 9:15 PM
To: Paul Kyzivat (pkyzivat)
Cc: [email-masked]
Subject: Re: [siprec] extensionData in XML

As someone who works quite a bit with XML, I'll point out that there is
an important distinction between data for extensibility and expected
application-specific data.  As an example of the latter, EMMA [1] is an
XML format for representing the input of a user (human being, commonly)
to an automated system, by speech, gesture, pen, etc.  Since the way an
input is interpreted is dependent upon its intended use, there was a
need for a designated application-specific section to represent the
semantics (meaning) of the input.
To make it easier for machine consumers of this format that may be
seeking the semantics, there is a designated element "interpretation"  
that holds this information.  The contents of this element are arbitrary
XML in an application-specific XML namespace.

On the other hand, every XML specification I've worked on in W3C has  
needed a way for implementers to innovate via extensions.   
Traditionally this is handled via custom elements and attributes in an
implementer-specific namespace to avoid name collision with the standard
elements and attributes.  Since these true innovation extensions can
occur anywhere, there is no specific XML element established in most
specifications for "extensions".  Instead, the specification defines the
expected behavior of a conformant processor upon encountering elements
and attributes outside of the specification's standard namespace.  The
nice thing about this approach is that allows for innovation in a way
that does not cause name collision but which could become part of the
standard in the future (and be moved into the standard's namespace).
For the specifications I worked on, we always required that a conformant
processor had to do the behavior defined in the specification when it
received a conformant document but that the behavior of the processor
when it encountered non-standard elements and attributes was at its own
discretion -- it could process the attributes, ignore them, or report an
error, as it deemed appropriate.

So the real question for us here is whether these extension elements are
*extensions* (which do not require a custom element/location) or
*expected application-specific information* (which can benefit from
custom elements and prescribed locations in the XML tree).

-- dan

On Apr 6, 2011, at 5:48 PM, Paul Kyzivat wrote:

>> Yes, I would be keen to hear Peter's or other opinions, but one other

>> point. One of the properties of XML is that it is human- readable. 
>> Having extension data as a child element of the element representing 
>> the object to which it applies seems, in my opinion, to make it more 
>> readable. Having extension data as a separate element, with a link to

>> the element to which it applies, seems hard for a human reader, 
>> particularly if the link is a long, random string.
>
> should function as much like the predefined parts as possible. 
> (Today's extension may become common usage tomorrow.)
>
>>> I already posted on this topic on the other thread. Partha states 
>>> below an additional motivation for handling extension data in the 
>>> way specified in the current I-D. My counter argument is that anyone

>>> behaviour when extension data is present in an object and then 
>>> absent when that object is updated. For some types of metadata it 
>>> could be that absence means it no longer applies, and for other 
>>> types of metadata it could be that absence means it has not changed.
>>>
>>> <partha>  Currently, metadata format draft XML element is written 
>>> with the basics that "it is no longer applies" in case specific 
>>> element is absent in the update. The question is how the information

>>> of extensiondata absence means "it is no longer applies" or "it has 
>>> not changed" has to be passed between SRC and SRS. Here, there is a 
>>> need of common understanding between SRC and SRS or else the 
>>> information will be misunderstand even though both parties 
>>> understand the specific extension.
>>>
>>> The current extensiondata is taken the route of all other metadata 
>>> block XML element definition. There may be better way to represent 
>>> in extensiondata XML element apart from creating new metadata block 
>>> with URN UUID. I'm including Peter for his advise on XML 
>>> front.</partha>
>>>
>>> The latter approach would avoid the need for repeating large 
>>> quantities of metadata each time there is a minor change to an 
>>> object.
>>>
>>> John (as individual)
>>>