[This local archive copy mirrored from the canonical site, converted from the DOC format: see http://www.fstc.org/projects/bips/spec/spec.zip; links may not have complete integrity, so use the canonical document at this URL if possible. On August 24, 1998, a specification for the Bank Internet Payment System (BIPS) was published: Bank Internet Payment System Specification Version 1.0. Public Review Draft, August 24, 1998. Appendix G of the specification supplies the 'XML Structure and Document Type Definition (DTD)'.]
Appendix G: XML Structure and Document Type Definition (DTD)
The BIPS DTD defines the structure of a BIPS message. In other words, it defines the elements, sub-elements, and attributes that may be included in a BIPS message. The advantage of defining these rules using a standard XML DTD is that it significantly relieves BIPS application developers of the burden of creating code to check message formats.
For those unfamiliar with XML and DTDs, this appendix provides a short primer and some notes about how BIPS implements XML (Section G.1). This appendix also contains the BIPS DTD (Section G.2), an example of a valid BIPS XML document (Section G.3), and a discussion of BIPS IDs (Section G.4).
Sections G.1.1 through G.1.4 describe some of the basics of how the structure rules of XML documents are defined, with occasional notes about how BIPS implements XML. However, this appendix is not intended to be an exhaustive discussion of XML; it is simply meant to enable readers that are unfamiliar with XML to better understand the BIPS DTD. For more information on DTDs and XML, see the W3C's Web site at http://www.w3c.org.
One of the reasons for the Web's astounding growth is the simplicity of HTML. Armed with just a text editor, even non-technical individuals can create HTML documents in a very short period of time. HTML was derived from the far more capable and complex SGML. But whereas SGML was defined to be capable of describing any document-from the Dead Sea Scrolls to the design of the Space Shuttle-HTML was defined mainly as a lightweight markup language for rendering and linking documents on the Web.
The problem with SGML is that it is too complicated for many people. Moreover, this complexity makes SGML software harder to develop. In contrast, the problem with HTML is that it is too simple. HTML includes a lexicon of about 90 or so tags that are hardwired into Web browsers. Because the HTML tags, such as <h1> for heading level one, do not describe the meaning of data they contain, HTML is not suitable for structured business documents, such as payment instructions, invoices, and so on. Enter XML.
As with SGML, XML documents can describe their own content. For example, the following XML document represents an invoice:
<invoice>
<date>June 1, 1998</date>
<due>July 1, 1998</due>
<amount>$100</amount>
</invoice>
Because the XML tags describe the content of a document, a computer program that reads the preceding XML could process it accordingly. The important difference between XML and SGML is that XML leaves out much of the complexity that makes SGML hard to work with. Consequently, it is easier to develop XML applications.
The most basic requirement of an XML document is that it be well-formed. A well-formed XML document has one root element for which neither the start nor the end tag is inside any other element, and all other element tags, or sub-elements, nest within each other correctly. The following is an example of a well-formed XML document.
<simple-root>
<simple-sub-element>
<simple-sub-sub-element>This is simple!</simple-sub-sub-element>
</simple-sub-element>
</simple-root>
Because the preceding example is a well-formed XML document, it can be successfully read, or parsed, by any standard XML parser. This is a key advantage of XML; it makes XML documents easy to work with and XML-based software more resilient. Moreover, it makes it possible to write programs that can process XML documents without having to reference an XML DTD, a topic that is discussed in Section G.1.3.
XML also specifies a few other rules, most of which were designed into the XML specification in order to make XML parsers easier to develop and more efficient. Two of these rules are:
<bill-name>PP&L's Monthly Invoice</bill-name>
<date day="01" month="06" year="1998"/>
As the preceding example demonstrates, empty XML elements can be thought of as having a self-contained starting and ending tag. In other words, empty XML elements must be delimited by "<" and "/>". NOTE: Another strict XML rule illustrated by the preceding example is that all XML attribute value pairs, such as in year="1998", must delimit values with quotes.
While in many cases there are great advantages to working with simple, well-formed XML documents, many sophisticated applications, such as BIPS, require stricter rules for document structure. A valid XML document conforms to the rules defined in its DTD.
A DTD can be contained within an XML document, as shown in the following valid XML document:
<?XML VERSION="1.0"?>
<!DOCTYPE body [
<!ELEMENT foo EMPTY>
<!ATTLIST foo
id ID #IMPLIED
linkend IDREF #IMPLIED>
]>
<body>
<foo id="foo" />
</body>
A DTD can also be defined in an external file, such as in the following example:
<?XML VERSION="1.0"?>
<!DOCTYPE body SYSTEM "body.dtd">
<body>
<foo id="foo" />
</body>
In the preceding example, an XML parser would find the DTD at the URL: "body.dtd", which is a file in the same directory as the XML document. The XML parser finds the DTD by looking at the document type declaration (not to be confused with the DTD itself), which is the tag <!DOCTYPE body SYSTEM "body.dtd">. BIPS requires the use of a standard pre-defined BIPS DTD, which, for security and efficiency reasons, is always external to a BIPS XML document.
When looking at a DTD, it helps to understand some basic concepts about DTD syntax. The main statements in the BIPS DTD are the element and attribute statements. The element statement defines the contents, which includes data and sub-elements that can be contained in an XML element. The attribute statement describes the attributes of a particular element. NOTE: Although you can also declare entities in a DTD, the BIPS DTD does not currently do this.
The following element declaration specifies that a bill element must contain exactly one date, due, and amount sub-elements:
<!ELEMENT bill (date, due, amount) >
It is also possible to define other syntax rules, such as optional elements or elements that can occur more than once. Table G.1 lists the characters that indicate these syntax rules:
Table G.1 Characters that indicate syntax.
Suffix Rule No Exactly one suffix , Defines sequential order * Zero or more + One or more ? One or none | Exclusive or
NOTE: In addition to the standard XML syntax rules defined in the BIPS DTD, BIPS implementations must ensure that BIPS XML documents do not contain comments. This is to help guard against cryptographic attacks.
The following statement is a good example of how XML element declarations work:
<!ELEMENT bill (date, due, amount, reference*, (account-number | customer-id) >
The element statement specifies that the sub-elements of any bill element must include exactly one date, due, and amount element, as well as either an account-number or a customer-id. The bill element can also have zero or more reference sub-elements
The BIPS DTD follows.
<!-- **************************************************************************************
** **
** Bank Internet Payment System (BIPS) Document Type Definition (DTD) **
** **
** Version: 1.0 **
** **
** Date Created: May 15, 1998 **
** **
** Create By: Jim Flynn, @Work Technologies **
** Email: jflynn@worktechs.com **
** Phone: (212) 571-3222 **
** **
** Date Modified: August 17, 1998 **
** Modified By: Jim Flynn, @Work Technologies **
** **
************************************************************************************** -->
<!-- **************************************************************************************
** **
** The bips element is the root element of all BIPS messages. It can contain **
** feasibility, payment, status, and stop messages (i.e. sub-elements). All BIPS **
** messages must be signed by using one or more signature-info elements. **
** Optionally, zero of more echo-signature-info elements can be passed between a **
** BIPS server and a BIPS-enabled client for added security. A receiving bank **
** can, for example, echo back the originator's signature. **
** **
** NOTE: Comments and internal DTDs are not permitted in BIPS messages. **
** Consequently, all BIPS-enabled applications must check for the **
** existence of comments and internal DTDs. Moreover, only the standard **
** DTD (i.e. this DTD) should be referenced by any BIPS message. **
** **
************************************************************************************** -->
<!ELEMENT bips (
message-id,
(
(
feasibility-request+ |
feasibility-response+ |
payment-request+ |
payment-response+ |
status-request+ |
status-response+ |
stop-request+ |
stop-response+
)
),
echo-signature*,
signature-info+
) >
<!ATTLIST bips
version CDATA "1.0" >
<!ELEMENT message-id EMPTY >
<!ATTLIST message-id
sender-id CDATA #REQUIRED
date CDATA #REQUIRED
sequence CDATA #REQUIRED >
<!-- **************************************************************************************
** **
** A feasibility-request message is used by BIPS-enabled client to query a BIPS **
** server regarding the possibility of making a payment request. By using a **
** feasibility-request, the user can, for example, find out the cost of making **
** a BIPS payment via a specific network. **
** **
************************************************************************************** -->
<!ELEMENT feasibility-request (
feasibility-request-id,
feasibility-request-info+
) >
<!ELEMENT feasibility-request-id (#PCDATA) >
<!-- *************************************************************************************
** **
** The feasibility-request-info element is where a BIPS-enabled client specifies **
** information about a potential payment request. This information may include **
** simple parameters, such as the payment network and amount, or an entire **
** potential payment request. **
** **
*************************************************************************************-->
<!ELEMENT feasibility-request-info (
(
(
payment-network,
amount?,
execute-date?,
value-date?,
bank-customer-info*
)+
) |
payment-request+
) >
<!-- *************************************************************************************
** **
** The feasibility-response message provides information to the BIPS-enabled **
** client regarding the feasibility of a specific payment request. **
** **
************************************************************************************* -->
<!ELEMENT feasibility-response (
feasibility-response-id,
request-message-id,
feasibility-request-id,
statement+
) >
<!ELEMENT feasibility-response-id (#PCDATA) >
<!ELEMENT request-message-id EMPTY >
<!ATTLIST request-message-id
sender-id CDATA #REQUIRED
date CDATA #REQUIRED
sequence CDATA #REQUIRED >
<!-- *************************************************************************************
** **
** The statement element is a generic structure for passing status, error, **
** informational, or other data from the BIPS server to a BIPS-enabled client. **
** It contains a standard BIPS code, standard description, as well as a **
** free-form contextual-info element. **
** **
************************************************************************************* -->
<!ELEMENT statement (
code,
description,
contextual-info
) >
<!ELEMENT code (#PCDATA) >
<!ELEMENT description (#PCDATA) >
<!ELEMENT contextual-info (#PCDATA) >
<!-- *************************************************************************************
** **
** The payment-request message is used by a BIPS-enabled client to send a BIPS **
** payment via a BIPS server. **
** **
************************************************************************************* -->
<!ELEMENT payment-request (
payment-request-id,
reference*,
execution-date,
value-date?,
(
payment-profile |
(
payment-network?,
amount,
details-of-charges?,
details-of-payment?,
notify*,
bank-to-bank-info?,
payor-to-payto-info?,
payor+,
payto+
)
)
) >
<!ELEMENT payment-request-id (#PCDATA) >
<!-- *************************************************************************************
** **
** The payment-profile element can be used to specify a reference to pre-defined **
** payment parameters. This can be useful, for example, for repetitive payments. **
** **
************************************************************************************* -->
<!ELEMENT payment-profile (#PCDATA) >
<!ELEMENT payor (
(
(
(
entity-profile |
entity
)?,
bank-customer-info
) |
payor-profile
),
amount?
) >
<!-- *************************************************************************************
** **
** The bank-customer-info element is used to identify a bank as well as a bank **
** account or bank customer id (which may ultimately map to an account number). **
** If the bank is being used as an intermediary in a transaction, the **
** intermediary flag must be set to "true". **
** **
************************************************************************************* -->
<!ELEMENT bank-customer-info (
bank,
(
(
account,
account-name?
) |
customer-id
)
) >
<!ATTLIST bank-customer-info
intermediary (
true |
false
) "false" >
<!ELEMENT bank (
bank-code,
entity?
) >
<!-- *************************************************************************************
** **
** The bank-code element is used to uniquely identify a financial institution. **
** The actual code used must be one of the BIPS-supported national codes, which **
** includes the following: **
** **
** bic - SWIFT Bank ID Code **
** ch - CHIPS Universal ID **
** cp - CHIPS Participant ID **
** fw - Fedwire Routing Number **
** trn - ACH Transit Routing Number **
** cc - Canadian Payments Association Payments Routing Number **
** sc - CHAPS Branch Sort Code **
** bl - German Bankleitzahl **
** swbc - Swiss Clearing Code (BC) **
** swsic - Swiss Clearing Code (SIC) **
** es - Spanish Domestic Interbanking Code **
** it - Italian Domestic ID Code **
** **
************************************************************************************* -->
<!ELEMENT bank-code (#PCDATA) >
<!ATTLIST bank-code
type (
bic |
ch |
cp |
fw |
trn |
cc |
sc |
bl |
swbc |
swsic |
es |
it
) #REQUIRED
branch CDATA #IMPLIED >
<!-- *************************************************************************************
** **
** Several BIPS elements, such as customer-id, can hold encrypted data. This **
** makes it possible, for example, to hide parts of a message from certain **
** individuals that may need to read other parts of the message. The encryption **
** attribute is used in BIPS to define the encryption algorithm, such as **
** "DES/ECB/PKCS5Padding" for DES encryption, electronic code book mode with **
** PKCS5 padding. The key-id attribute species a unique cryptographic key that **
** can be used to encrypt and decrypt the element data. This key may be **
** exchanged out-of-band. All encrypted data should be encoded by using base64 **
** encoding, which is defined by the encoding attribute. **
** **
** NOTE: When symmetric encryption is used, such as DES, a key-id attribute **
** should also be specified. **
** **
************************************************************************************* -->
<!ELEMENT customer-id (#PCDATA) >
<!ATTLIST customer-id
id ID #IMPLIED
encryption CDATA "none"
key-id CDATA #IMPLIED
encoding (
BASE64
) #IMPLIED >
<!ELEMENT account (#PCDATA) >
<!ATTLIST account
type CDATA #IMPLIED
id ID #IMPLIED
encryption CDATA "none"
key-id CDATA #IMPLIED
encoding (
BASE64
) #IMPLIED >
<!ELEMENT account-name (#PCDATA) >
<!ELEMENT entity-profile (#PCDATA) >
<!ELEMENT entity (
name*,
contact*,
location*,
phone*,
fax*,
email*
) >
<!ELEMENT name (#PCDATA) >
<!ELEMENT location (
address*,
city?,
region?,
postal?,
country?
) >
<!ELEMENT payto (
(
(
(
entity-profile |
entity
)?,
bank-customer-info
) |
payto-profile
),
amount?,
foreign-exchange-info?
) >
<!ELEMENT reference (#PCDATA) >
<!ATTLIST reference
type CDATA #IMPLIED >
<!ELEMENT execution-date (
month,
day,
year,
time?
) >
<!ELEMENT value-date (
month,
day,
year,
time?
) >
<!-- *************************************************************************************
** **
** The time element includes a zone attribute, which indicates the time zone. **
** BIPS time zones can be: **
** **
** est - Eastern Standard Time (USA) **
** cst - Central Standard time (USA) **
** mst - Mountain Standard Time (USA) **
** pst - Pacific Standard Time (USA) **
** gmt - Greenwich Mean Time **
** **
** The default is value for the zone attribute is gmt. **
** **
************************************************************************************* -->
<!ELEMENT time (
hour,
minute?,
second?,
millisecond?
) >
<!ATTLIST time
zone (
est |
cst |
mst |
gmt |
) "gmt" >
<!-- *************************************************************************************
** **
** The hour element should be specified by a numeric hour between 1 and 24. **
** **
************************************************************************************* -->
<!ELEMENT hour (#PCDATA) >
<!-- *************************************************************************************
** **
** The minute element should be specified by a numeric minute between 1 and 60. **
** **
************************************************************************************* -->
<!ELEMENT minute (#PCDATA) >
<!-- *************************************************************************************
** **
** The second element should be specified by a numeric second between 1 and 60. **
** **
************************************************************************************* -->
<!ELEMENT second (#PCDATA) >
<!-- *************************************************************************************
** **
** The millisecond element should be specified by a numeric millisecond between **
** 1 and 1000. **
** **
************************************************************************************* -->
<!ELEMENT millisecond (#PCDATA) >
<!-- *************************************************************************************
** **
** The ccy attribute of the amount element must be a standard ISO currency code. **
** **
************************************************************************************* -->
<!ELEMENT amount (#PCDATA) >
<!ATTLIST amount
encryption CDATA "none"
key-id CDATA #IMPLIED
encoding (
BASE64
) #IMPLIED
ccy (
AED | AFA | ALL | AMD | ANG |
AOK | AON | ARA | ARS | ATS |
AUD | AWG | AZM | BAD | BBD |
BDT | BEF | BGL | BHD | BIF |
BMD | BND | BOB | BRE | BRL |
BRR | BSD | BTN | BWP | BYB |
BZD | CAD | CDF | CHF | CLP |
CNY | COP | CRC | CUP | CVE |
CYP | CZK | DEM | DJF | DKK |
DOP | DZD | ECS | EEK | EGP |
ERB | ESP | ETB | EUR | FIM |
FJD | FKP | FRF | GBP | GEL |
GHC | GIP | GMD | GNF | GNS |
GQE | GRD | GTQ | GWP | GYD |
HKD | HNL | HRK | HTG | HUF |
IDR | IEP | ILS | INR | IQD |
IRR | ISK | ITL | JMD | JOD |
JPY | KES | KGS | KHR | KMF |
KPW | KWD | KYD | KZT | LAK |
LBP | LKR | LRD | LSL | LTL |
LUF | LVL | LYD | MAD | MDL |
MGF | MKD | MLF | MMK | MNT |
MOP | MRO | MTL | MUR | MVR |
MWK | MXP | MYR | MZM | NAD |
NGN | NIC | NLG | NOK | NPR |
NZD | OMR | PAB | PEI | PEN |
PGK | PHP | PKR | PLZ | PTE |
PYG | QAR | ROL | RUR | RWF |
SAR | SBD | SCR | SDP | SEK |
SGD | SHP | SIT | SKK | SLL |
SOS | SRG | STD | SVC | SYP |
SZL | THB | TJR | TMM | TND |
TOP | TRL | TTD | TWD | TZS |
UAH | UGS | UGX | USD | UYN |
UYP | UYU | UZS | VEB | VND |
VUV | WST | XAF | XCD | XDR |
XEU | XOF | XPF | YER | YUN |
ZAR | ZMK | ZRN | ZWD
) "USD" >
<!-- *************************************************************************************
** **
** If the ccy of an output amount element is different than that of the input **
** amount, then the BIPS-enabled client may specify a foreign-exchange-info **
** element. The foreign-exchange-info element must contain a rate (i.e. **
** exchange rate) attribute and an optional rate-reference attribute, which **
** may have been provided by the bank along with a rate quotation. **
** **
************************************************************************************* -->
<!ELEMENT foreign-exchange-info (EMPTY) >
<!ATTLIST foreign-exchange-info
rate CDATA #REQUIRED
rate-reference CDATA #IMPLIED >
<!ELEMENT details-of-charges (#PCDATA) >
<!ELEMENT details-of-payment (#PCDATA) >
<!ELEMENT bank-to-bank-info (#PCDATA) >
<!ELEMENT payor-to-payto-info (#PCDATA) >
<!ELEMENT notify (
entity |
entity-profile
) >
<!ATTLIST notify
event (
success |
error |
all
) "success"
method CDATA #IMPLIED >
<!-- *************************************************************************************
** **
** The payment network element must be specified as one of the supported BIPS **
** payment networks or "other", which can be, for example, a bank-specific **
** payment network, such as "XYZBankNet". **
** **
************************************************************************************* -->
<!ELEMENT payment-network (
ach |
swift |
fedwire |
chips |
other
) >
<!ELEMENT ach EMPTY >
<!ATTLIST ach
type (
ccd |
ppd |
ctx |
cie
) #IMPLIED >
<!ELEMENT swift EMPTY >
<!ATTLIST swift
type (
100 |
102 |
200 |
202 |
203
) #IMPLIED >
<!ELEMENT fedwire EMPTY >
<!ATTLIST fedwire
type CDATA #IMPLIED >
<!ELEMENT chips EMPTY >
<!ATTLIST chips
type CDATA #IMPLIED >
<!ELEMENT other EMPTY >
<!ATTLIST other
network-name CDATA #REQUIRED
type CDATA #IMPLIED >
<!ELEMENT contact (#PCDATA) >
<!ELEMENT address (#PCDATA) >
<!ELEMENT email (#PCDATA) >
<!ELEMENT phone (#PCDATA) >
<!ATTLIST phone
type (
business |
fax |
cellular |
home |
temporary |
other
) "business" >
<!-- *************************************************************************************
** **
** The month element should be specified by a numeric month between 1 and 12. **
** **
************************************************************************************* -->
<!ELEMENT month (#PCDATA) >
<!-- *************************************************************************************
** **
** The day element should be specified by a numeric day between 1 and 31. **
** **
************************************************************************************* -->
<!ELEMENT day (#PCDATA) >
<!-- *************************************************************************************
** **
** The year element should be specified by a 4 digit numeric year, such as **
** 1998, 2001 and so on. **
** **
************************************************************************************* -->
<!ELEMENT year (#PCDATA) >
<!-- *************************************************************************************
** **
** The payment-response message provides information to a BIPS-enabled client **
** regarding the initial success or failure of a BIPS payment request. **
** **
************************************************************************************* -->
<!ELEMENT payment-response (
payment-response-id,
request-message-id,
payment-request-id,
statement+
) >
<!ELEMENT payment-response-id (#PCDATA) >
<!-- *************************************************************************************
** **
** The status-request enables a BIPS-enabled client to query a BIPS server **
** regarding the status of a specific BIPS payment or stop request. **
** **
************************************************************************************* -->
<!ELEMENT status-request (
status-request-id,
payment-request-message-id,
payment-request-id
) >
<!ELEMENT status-request-id (#PCDATA) >
<!-- *************************************************************************************
** **
** The status-response message provides information to the BIPS-enabled **
** client regarding the status of a specific BIPS payment request. **
** **
************************************************************************************* -->
<!ELEMENT status-response (
status-response-id,
request-message-id,
status-request-id,
statement+
) >
<!ELEMENT status-response-id (#PCDATA) >
<!-- *************************************************************************************
** **
** The stop-request message enables a BIPS-enabled client to request that a **
** previously requested BIPS payment request be cancelled. **
** **
************************************************************************************* -->
<!ELEMENT stop-request (
stop-request-id,
request-message-id,
payment-request-id
) >
<!ELEMENT stop-request-id (#PCDATA) >
<!-- *************************************************************************************
** **
** The stop-response message provides information to a BIPS-enabled client **
** regarding the action(s) taken with respect to a stop request. **
** **
** NOTE: A stop transaction may have to be transmitted to a legacy payment **
** system. A BIPS-enabled client can query the status of a stop transaction **
** by using a status-request message. **
** **
************************************************************************************* -->
<!ELEMENT stop-response (
stop-response-id,
request-message-id,
stop-request-id,
statement+
) >
<!ELEMENT stop-response-id (#PCDATA) >
<!-- **************************************************************************************
** **
** An echo-signature-info element can be used by clients and servers to echo **
** signatures back to one another for specific request or response messages. **
** This option can be used to ensure that a message was not corrupted or **
** subverted while in transit. **
** **
** An echo-signature-info element must include the IDs of all the requests or **
** responses that the echoed signature was used to sign. **
** **
************************************************************************************** -->
<!ELEMENT echo-signature-info (
(
feasibility-request-id |
feasibility-response-id |
payment-request-id |
payment-response-id |
status-request-id |
status-response-id |
stop-request-id |
stop-response-id
)+,
signature
) >
<!-- **************************************************************************************
** **
** BIPS supports DSA (with a SHA-1 hash) and RSA (with an MD5 digest) signatures. **
** The signatures must be encoded as ASCII characters by using BASE64. **
** **
************************************************************************************** -->
<!ELEMENT signature (#PCDATA) >
<!ATTLIST signature
algorithm (
RSA |
DSA
) #REQUIRED
encoding (
BASE64
) #IMPLIED >
<!-- **************************************************************************************
** **
** A signature-info element signs the entire BIPS message whenever a **
** signed-element-name is not specified. If a signed-element-name is specified, **
** the signature-info applies only to the specified element. If the signed **
** element is not unique to a message, then it must be identified by a unique **
** attribute value or id sub-element value. **
** **
** Multiple signature-info elements can be used to enable multiple individuals to **
** sign the same payment. **
** **
************************************************************************************** -->
<!ELEMENT signature-info (
(
signed-element-name,
(
id-element-value? |
id-attribute-value
)
)?,
signature,
certificate
) >
<!ELEMENT id-element-value (#PCDATA) >
<!ELEMENT id-attribute-value (#PCDATA) >
<!-- **************************************************************************************
** **
** BIPS supports X509 certificates versions 1 through 3. The certificates must be **
** encoded as ASCII characters by using BASE64. **
** **
************************************************************************************** -->
<!ELEMENT certificate (#PCDATA) >
<!ATTLIST certificate
type (
X509
) #IMPLIED
version (
V1 |
V2 |
V3
) #IMPLIED
encoding (
BASE64
) #IMPLIED >
This section contains an example of a valid BIPS message for an ACH payment request.
<?XML VERSION="1.0" ?>
<!DOCTYPE bips SYSTEM "bips.dtd">
<bips version="1.0">
<message-id sender-id="jflynn@worktechs.com" date="19980504" sequence="2"/>
<payment-request>
<payment-request-id>1</payment-request-id>
<reference>payroll</reference>
<execution-date>
<month>05</month>
<day>04</day>
<year>1998</year>
</execution-date>
<payment-network>
<ach type="ccd"/>
</payment-network>
<amount>1000</amount>
<payor>
<entity>
<name>Jim Flynn</name>
<location>
<address>111 John Street</address>
<address>Suite 2509</address>
<city>New York</city>
<region>NY</region>
<postal>10038</postal>
</location>
<phone>(212) 571-3222</phone>
<fax>(212) 571-3213</fax>
<email>jflynn@worktechs.com</email>
</entity>
<bank-customer-info>
<bank>
<bank-code type="trn">12345678</bank-code>
<entity>
<name>Citibank</name>
<location>
<address>3rd Avenue</address>
<address></address>
<city>New York</city>
<region>NY</region>
<postal>10022</postal>
</location>
<phone>(212) 555-5555</phone>
<fax>(212) 444-4444</fax>
<email>info@citicorp.com</email>
</entity>
</bank>
<account type="checking">87654321</account>
</bank-customer-info>
</payor>
<payto>
<entity>
<name>Bill Clarke</name>
<location>
<address>4 Jeferson Street</address>
<address>Apt 4D</address>
<city>Hoboken</city>
<region>NJ</region>
<postal>98765</postal>
</location>
<phone>(201) 799-1122</phone>
</entity>
<bank-customer-info>
<bank>
<bank-code type="trn">87654321</bank-code>
<entity>
<name>Mellon Bank</name>
<location>
<address>3 Mellon Bank Plaza</address>
<city>Pittsburgh</city>
<region>PA</region>
<postal>99999</postal>
</location>
<phone>(333) 333-3333</phone>
<fax>(333) 333-3232</fax>
<email>info@melon.com</email>
</entity>
</bank>
<customer-id>22222222</customer-id>
</bank-customer-info>
</payto>
</payment-request>
<signature-info>
<signature algorithm="DSA">MCwCFFLeSiaBHjxirD/J21+fWI8/9SEOAhRpk8HSKZFOCSzZJbbYm9bn3jvmCA==</signature>
<certificate>MIIC9zCCArQCBDUjfAYwCwYHKoZIzjgEAwUAMGExCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJOWTERMA8GA1UEBxMITmV3IFlvcmsxDjAMBgNVBAoTBUBXb3JrMQ4wDAYDVQQLEwVAV29yazESMBAGA1UEAxMJSmltIEZseW5uMB4XDTk4MDQwMjExNTIzOFoXDTk4MDcwMTExNTIzOFowYTELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAk5ZMREwDwYDVQQHEwhOZXcgWW9yazEOMAwGA1UEChMFQFdvcmsxDjAMBgNVBAsTBUBXb3JrMRIwEAYDVQQDEwlKaW0gRmx5bm4wggG3MIIBLAYHKoZIzjgEATCCAR8CgYEA/X9TgR11EilS30qcLuzk5/YRt1I870QAwx4/gLZRJmlFXUAiUftZPY1Y+r/F9bow9subVWzXgTuAHTRv8mZgt2uZUKWkn5/oBHsQIsJPu6nX/rfGG/g7V+fGqKYVDwT7g/bTxR7DAjVUE1oWkTL2dfOuK2HXKu/yIgMZndFIAccCFQCXYFCPFSMLzLKSuYKi64QL8Fgc9QKBgQD34aCF1ps93su8q1w2uFe5eZSvu/o66oL5V0wLPQeCZ1FZV4661FlP5nEHEIGAtEkWcSPoTCgWE7fPCTKMyKbhPBZ6i1R8jSjgo64eK7OmdZFuo38L+iE1YvH7YnoBJDvMpPG+qFGQiaiD3+Fa5Z8GkotmXoB7VSVkAUw7/s9JKgOBhAACgYALw0r4cS0307IWg6OPQ1q12Fp7DhufWWHrM88JfsbO7PkPPI+tL+qeZzABjU3LB1+XYNsIv2lw0JJPZYbWQiolOBliOT59DDdfirNKiOYpYzlfVv3q9GWJgQd5HLsP/gZGpIJQV6unyH/AU9LG7A/xLnLaZexfXVTkA/dX5R+bFzALBgcqhkjOOAQDBQADMAAwLQIVAIZ7Qd21DTnpcpEHwY4lFOg9E2BnAhQGktVkce5+nmLXm1XlSWF75yWO4w==</certificate>
</signature-info>
</bips>
This section contains a list of the reference elements used to identify BIPS messages (Section G.4.1) and an explanation of how BIPS IDs are generated (Section G.4.2).
Each BIPS message contains exactly one message-id element that uniquely identifies the message. Because a BIPS message can contain multiple requests or responses, each individual request or response also has its own ID, which must be unique within a BIPS message. BIPS relies on the following reference elements to identify individual requests or responses within a BIPS message:
Because each BIPS message has a unique ID, it can be referenced in the future. This ability to reference specific BIPS messages, as well as the individual requests and responses within messages, makes it possible, for example, to send a BIPS payment-request message over a store-and-forward network and then match it to a payment-response that may be received later.
In addition to the preceding list of IDs, BIPS also utilizes the following transaction IDs:
Payment and stop transactions have separate and unique IDs because they exist outside of BIPS and separately from the BIPS messages that generated them.
Unique BIPS message IDs are generated in the following XML element format:
<message-id sender-id="ENTITYID" date="YYYYMMDD" sequence="N"/>
In the preceding element description, the sender-id attribute's value, "ENTITYID", could be the server's URL or an Internet email address. The date attribute's value, "YYYYMMDD", is composed of the date. The sequence attribute's value, "N", is a sequential number indicating the order of messages sent on the specified date. In cases where there may be many BIPS servers in a load-balanced configuration, which may make the server appear as one URL, processing logic must be implemented to ensure that two different servers do not reuse the same sequence number.
The following is an example of a BIPS message-id element:
<message-id sender-id="jflynn@worktechs.com" date="19980504" sequence="2"/>
The preceding message-id element uniquely identifies a message sent by an entity with the Internet email address "jflynn@worktechs.com". The message is the second message sent by this sender-id on May 4th, 1998. It is also important to note that the identity of the sender is cross-checked when the message's embedded X.509 certificate and digital signature is validated by either a BIPS server or a BIPS-enabled client.