OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-transport message

[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]

Search: Match: Sort by:
Words: | Help


Powered by eList eXpress LLC