[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  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  containing numeric digits only (i.e. no punctuation) h323 H.323 identifier url Uniform Resource Locator  email electronic mail address  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  national national party number  network network specific party number  subscriber subscriber party number  abbreviated abbreviated party number  e164prefix initial (most significant) digits of an E.164 number  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 <firstname.lastname@example.org> on 12/13/2000 08:11:07 AM To: "William J. Kammerer" <email@example.com> cc: "ebXML Transport (E-mail)" <firstname.lastname@example.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) email@example.com, Fax: 512-838-1074 "William J. Kammerer" <firstname.lastname@example.org> on 12/13/2000 08:40:51 AM To: "ebXML Transport (E-mail)" <email@example.com> 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" <firstname.lastname@example.org> To: "ebXML Transport (E-mail)" <email@example.com> 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