[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: proposal: collapse To and From elements
Hi,
I can add some insight on how we handled a similar issue when we drafted the ETSI TIPHON OSP:
http://www.oasis-open.org/cover/openSetProt.html
(For more information, the following are several articles/papers on the
ETSI TIPHON Open Settlement Protocol (OSP):
a. http://www.tmcnet.com/articles/itmag/0499/0499cisco.htm
b.
http://www.infoworld.com/cgi-bin/displayArchive.pl?/98/37/n01-37.37.htm
c. http://www.oasis-open.org/cover/openSetProt.html
d. http://www.cisco.com/warp/public/cc/so/neso/vvda/pctl/clear/osp_qp.htm
e. http://www.lucent.com/press/0499/990413.nsa.html)
The ETSI TIPHON OSP uses SourceInfo, SourceAlternate, DestinationInfo, and
DestinationAlternate for the ebXML 'From', 'From (multiple)',
'To', 'To (multiple)' elements:
6.2 Components
...
6.2.3 AuthorizationRequest
<!ELEMENT AuthorizationRequest ( Timestamp, CallId*, SourceInfo, SourceAlternate*,
DestinationInfo, DestinationAlternate*, Service, MaximumDestinations ) >
<!ATTLIST AuthorizationRequest componentId ID #REQUIRED >
An AuthorizationRequest asks for authorization to use resources. In the context of basic Internet telephony service, it asks for authorization
to complete a phone call. The call, for example, may be identified by E.164 numbers [12] in the SourceInfo and DestinationInfo elements.
The requesting system may leave the choice of peer endpoints up to the authorizing server, or it may specify the peer endpoint itself in a
DestinationAlternate element.
The client may provide one or more CallId elements in the request. A single CallId element implies that the client wishes to use that call
identifier for all possible destinations returned in the AuthorizationResponse. Multiple CallId elements imply that the client wishes each
potential destination to have its own call identifier. If the client wishes to specify multiple call identifiers, the number of CallId elements
shall be equal to the value of the MaximumDestinations element.
6.2.7 UsageIndication
<!ELEMENT UsageIndication ( Timestamp, Role, TransactionId, CallId, SourceInfo, SourceAlternate*,
DestinationInfo, DestinationAlternate*, UsageDetail*, StartTime, EndTime?, TerminationCause ) >
<!ATTLIST UsageIndication componentId ID #REQUIRED >
The UsageIndication component reports resource usage. In the context of basic Internet telephony service, this is typically call duration.
...
6.3 Elements
This subclause defines the individual elements that make up each message component.
...
6.3.87 Destination
<!ELEMENT Destination ( DestinationInfo?, DestinationAlternate*, DestinationSignalAddress, Token*,
ValidAfter?, ValidUntil?, UsageDetail*, AuthorityURL*, CallId )>
<!ATTLIST Destination critical (True | False) "True">
The Destination element is the parent element for call routing information, and it is returned by servers in an AuthorizationResponse
messages. As the above definition shows, as many as nine different types of subelements may comprise a Destination element.
6.3.98 DestinationAlternate
<!ELEMENT DestinationAlternate (#PCDATA)>
<!ATTLIST DestinationAlternate type ( e164 | h323 | url | email | transport |
international | national | network |
subscriber | abbreviated | e164prefix ) #REQUIRED
critical ( True | False ) "True" >
The DestinationAlternate element contains secondary identification of the destination. This information provides an alternative to the
DestinationInfo element. DestinationAlternate uses the same notation as DestinationInfo.
6.3.109 DestinationInfo
<!ELEMENT DestinationInfo (#PCDATA)>
<!ATTLIST DestinationInfo type ( e164 | h323 | url | email | transport |
international | national | network |
subscriber | abbreviated | e164prefix ) #REQUIRED
critical ( True | False ) "True" >
The DestinationInfo element gives the primary identification of the destination, or called party, for a call. The element includes a type
attribute, and can take one of several forms depending on the value of that attribute.
The following list indicates the contents of the element, given each possible attribute type.
e164 full E.164 telephone number [12] containing numeric digits only (i.e. no punctuation)
h323 H.323 identifier
url Uniform Resource Locator [13]
email electronic mail address [13]
transport transport address is the form of name:nn where name is the domain name (or IP address enclosed in square brackets) and
:nn is an (optional) TCP or UDP port number, (e.g. [172.16.1.1]:112)
international international party number [13]
national national party number [13]
network network specific party number [13]
subscriber subscriber party number [13]
abbreviated abbreviated party number [13]
e164prefix initial (most significant) digits of an E.164 number [12] with no punctuation
6.3.110 DestinationSignalAddress
<!ELEMENT DestinationSignalAddress (#PCDATA)>
<!ATTLIST DestinationSignalAddress critical (True | False) "True">
The DestinationSignalAddress element identifies the call signalling address for the destination. It is represented as name:nn, where name is
a domain name or an IP address enclosed in square brackets. The :nn is optional and indicates a TCP port number. For example, call signalling to
device gateway.operator.com at TCP port number 112 is represented as follows.
<DestinationSignalAddress>
gateway.operator.com:112
</DestinationSignalAddress>
...
6.3.175 SourceAlternate
<!ELEMENT SourceAlternate (#PCDATA)>
<!ATTLIST SourceAlternate type ( e164 | h323 | url | email | transport |
international | national | network |
subscriber | abbreviated | e164prefix ) #REQUIRED
critical ( True | False ) "True" >
The SourceAlternate element contains secondary identification of the source of a call. It conforms to the same notation as the
DestinationInfo element.
6.3.186 SourceInfo
<!ELEMENT SourceInfo (#PCDATA)>
<!ATTLIST SourceInfo type ( e164 | h323 | url | email | transport |
international | national | network | subscriber |
abbreviated | e164prefix ) #REQUIRED
critical ( True | False ) "True" >
The SourceInfo element contains the primary identification of the source of a call. It uses the same notation as the DestinationInfo
element.
6.3.197 SourceSignalAddress
<!ELEMENT SourceSignalAddress (#PCDATA)>
<!ATTLIST SourceSignalAddress critical (True | False) "True">
The SourceSignalAddress element identifies the call signalling address of the source of a call. It uses the same notation as the
DestinationSignalAddress element.
An example of using alternate addresses is shown in the following example:
E.3 Usage Exchange
The final examples demonstrate the exchange of usage information. The first message reports a call duration of 10 minutes.
POST scripts/settlements HTTP/1.0
content-type: multipart/signed;
protocol="application/pkcs7-signature";
micalg=sha1;
boundary=bar
content-length: 1246
--bar
Content-Type: text/plain
Content-Length: 926
<?xml version=1.0?>
<Message messageId="123454321" random="12345678">
<UsageIndication componentId="13579990">
<Timestamp>
1998-04-24T22:03:00Z
</Timestamp>
<Role>
source
</Role>
<TransactionId>
67890987
</TransactionId>
<CallId encoding="base64">
YT64VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756t
</CallId>
<SourceInfo type="e164">
81458811202
</SourceInfo>
<SourceAlternate type="subscriber">
8912342718473772
</SourceAlternate>
<DestinationInfo type="e164">
4766841360
</DestinationInfo>
<DestinationAlternate type="transport">
[10.0.1.2]:112
</DestinationAlternate>
<UsageDetail>
<Service/>
<Amount>
10
</Amount>
<Increment>
60
</Increment>
<Unit>
s
</Unit>
</UsageDetail>
<StartTime>
1999-05-02T19:03:00Z
</StartTime>
<EndTime>
1999-05-02T19:13:00Z
</EndTime>
<TerminationCause>
<TCCode>
1016
</TCCode>
<Description>
normal call clearing
</Description>
</TerminationCause>
</UsageIndication>
</Message>
--bar
Content-Type: application/pkcs7-signature
Content-Length: 191
GhyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT64VQpfyF467GhIGfH
fYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnjn8HHGTrfvhJhjH776tbB9HG4VQbnj756
7GhIGfHfYT6ghyHhHUujpfyF47GhIGfHfYT64VQbnj756
--bar--
Clients of the ebXML messaging service may wish to provide one or more destinations (to) elements AND
one or more alternate address types FOR EACH destination - for example, uri, url, email, transport, international, national, network,
abbreviated, and e164prefix.
Regards,
Erik J Leckner
Seagate Technology, LLC
regards,
erik j leckner
seagate technologu, llc
Scott Hinkelman <srh@us.ibm.com> on 12/13/2000 08:11:07 AM
To: "William J. Kammerer" <wkammerer@foresightcorp.com>
cc: "ebXML Transport (E-mail)" <ebxml-transport@lists.ebxml.org>
Subject: Re: proposal: collapse To and From elements
William says "some compatibility between RN and ebXML might be desirable".
I say "compatibility between RN and ebXML is desirable".
With all of the efforts/products emerging within the related space of
ebXML, I increasingly believe
that enabling RN with ebXML is important for ebXML traction.
My view is that if it decreases RN enablement on ebXML, don't change it.
Scott Hinkelman, Senior Software Engineer
XML Industry Enablement
IBM e-business Standards Strategy
512-823-8097 (TL 793-8097) (Cell: 512-940-0519)
srh@us.ibm.com, Fax: 512-838-1074
"William J. Kammerer" <wkammerer@foresightcorp.com> on 12/13/2000 08:40:51
AM
To: "ebXML Transport (E-mail)" <ebxml-transport@lists.ebxml.org>
cc:
Subject: Re: proposal: collapse To and From elements
Chris:
The example I gave mimicked somewhat the example in RNIF V2, where they
use DUNS all the time, but still they had an internal routing gimmick;
some compatibility between RN and ebXML might be desirable.
<Party> should specify IDs which would be known to the transport
mechanism (like URLs; or in the case of VANs, TP IDs in the form of
DUNS, etc.) Even though a TP might want all messages to go to the same
MSH using a known ID, the recipient may want to separate messages
according to business function or unit, without looking inside the
payload documents, once the message arrives within their firewall. Most
importantly, the Internal Routing specification may be known only to the
sender and receiver, and VANs or software in between may have no idea
how to interpret the Internal Routing - they can only carry the data
along in the message header. I suppose <ServiceInterface> and <Action>
could be used for this particular culling, but my point was there could
be some additional junk we discover that needs to added to <To> and
<From> , and if they're collapsed now, graceful ways of extending them
will be precluded.
Internal business units certainly can be identified with DUNS+4 (and X12
and EDIFACT make allowances for this), but DUNS+4 is far more likely to
be exchanged between business partners as application data.
William J. Kammerer
FORESIGHT Corp.
4950 Blazer Memorial Pkwy.
Dublin, OH USA 43017-3305
+1 614 791-1600
Visit FORESIGHT Corp. at http://www.foresightcorp.com/
"Commerce for a New World"
----- Original Message -----
From: "christopher ferris" <chris.ferris@east.sun.com>
To: "ebXML Transport (E-mail)" <ebxml-transport@lists.ebxml.org>
Sent: Wednesday, December 13, 2000 7:28 AM
Subject: Re: proposal: collapse To and From elements
William,
I'm not sure what you mean by "pretty". No one ever said
angle brackets were "pretty";-)
You do raise an interesting point. However, isn't
this sort of "internal" routing supposed to be
addressed with DUNS+4 (assuming that DUNS is used as
a Party identifier)?
Cheers,
Chris
"William J. Kammerer" wrote:
>
> What if some day you wanted to add internal routing specifications to
> either the <From> or <To> specifications, à la RosettaNet's (V2)
> optional <locationID> within <PartnerIdentification>?
>
> <To>
> <Party context="uri">urn:duns:123456789</Party>
> <InternalRouting>Columbus office</InternalRouting>
> </To>
>
> I suppose <InternalRouting> could be made another attribute of the
newly
> "collapsed" <To> and <From> elements, but...
>
> Also, I've got a gut feel against having different leaf-node elements
> which are a whole lot like other elements (even if they're easy enough
> to define in a schema). If and when we ever got Core Component Design
> Rules, would the type of collapsing described by Christopher Ferris be
> considered pretty?
>
> William J. Kammerer
> FORESIGHT Corp.
> 4950 Blazer Memorial Pkwy.
> Dublin, OH USA 43017-3305
> +1 614 791-1600
>
> Visit FORESIGHT Corp. at http://www.foresightcorp.com/
> "Commerce for a New World"
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC