BDXR Terminology

Access Point: PEPPOL terminology for "gateway". The name "Access Point" refers to the gateway being the point where a trading partner or connecting network accesses the PEPPOL infrastructure.
Business document: Generally refers to structured information that is exchanged between two parties with a mutual business relation.
Business identifier: Same as a party identifier.
Cloud: In BDXR terminology refers to any communications network or infrastructure.
Community: A group of individual parties who are capable of exchanging business documents, either by being connected to the same service (i.e. a three-corner architecture) or by the use of intermediaries connected in a four-cornered infrastructure.
Corner 1: Refers to the trading partner or connecting domain that is sending a business document through a four-cornered infrastructure.
Corner 2: Refers to the gateway of the sending party or domain in a four-cornered architecture, i.e. the gateway acting as intermediary for Corner 1.
Corner 3: Refers to the gateway of the receiving party or domain in a four-cornered architecture, i.e. the gateway acting as intermediary for Corner 4.
Corner 4: Refers to the trading partner or connecting domain that is receiving a business document sent through a four-cornered infrastructure.
DDDS: Dynamic Delegation Discovery Service, whose core parts are specified in five RFCs 3401 through 3405. Specific DDDS applications are found in VOIP, SIP and many other specifications.
DDDS application: The sequence of processing steps involved when using several DNS queries to produce a desired discovery result.
DNS query: A DNS query made to a DNS nameserver for specific or any RRs indexed by a query string. A query string is a "domain name consisting of one or more parts, technically called labels, that are conventionally concatenated, and delimited by dots, such as example.com". A hostname is a domain name that "has at least one IP address associated with it". The names allowed are specified by RFCs 1035, 1123, 2181 and updated by ICANN Internationalizing Domain Names in Applications (IDNA) which uses the Punycode mapping of UNICODE. Technically domain name labels are limited to 63 octets, and a full name is restricted to 253 octets. Supposedly any binary octet string is allowed as a label (RFC 2181, section 11). But for TLDs, the working rule has been case-independent "letters/digits/hyphens" in labels. RFCs do specify DNS labels using octets other than letters/digits/hyphens.
DNSSEC: Pertains to RRs that enable signing of RRs.
Domain: A domain in BDXR refers to any community whose members are connected through a shared system and may interact with others across domains.
e-CODEX: A Large Scale Pilot established to improve the cross-border access of citizens and businesses to legal means in Europe as well as to improve the interoperability between legal authorities within the EU.
http://www.e-codex.eu
End-user: The user/customer of a service provider.
Four-corner model: The four-corner model describes an architecture where trading partners and/or connected domains exchange business documents through the use of gateways. The four-corner model allows for trading partners to choose a gateway service that matches their individual needs and requirements rather than be "locked in" using a shared service as in the three-cornered model. The four-corner model also allows three-cornered and other four-cornered communities to exchange business documents across domains.
Gateway: A gateway is what connects trading partners and domains together in a four-cornered infrastructure. Corner 2 is the gateway of corner 1, and corner 3 is the gateway of corner 4.

As is in the definition, a gateway always has two sides: One side that connects to other gateways in the infrastructure (i.e. connecting corner 2 to corner 3), and one side that connects to a trading partner or connecting domain (connecting corner 2 to corner 1, and corner 3 to corner 4). The side of a gateway that connects to other gateways within the four-cornered infrastructure must always follow agreed standards and specifications. The side of the gateway that connects with the trading partner or connecting domain is generally not standardized, though there are environments where some level of standardization is needed (e.g. to support encrypted or digitally signed business documents, end-to-end evidence of delivery etc.).
Large Scale Pilot: ICT projects to enhance pan-European interoperability within specific areas involving public administration. Large Scale Pilots (or LSPs) are run by European Union member states with support and co-funding from the European Commission.
http://ec.europa.eu/information_society/activities/egovernment/lsp/index_en.htm
LSP: Abbreviation for "Large Scale Pilot".
Message: Refers to the payload of a communication between two entities, i.e. a "business document".
Multi-corner model: Same as four-corner model.
Organization: Potentially automated system.
Participant: In PEPPOL terminology, a participant is an organization or legal entity that connects to the PEPPOL infrastructure through an Access Point in order to exchange business documents with other participants. Participants are the originators and final destinations of business documents. Basically "trading partners".
Party identifier: A code or address that uniquely identifies a trading partner. A party identifier may or may not be authoritatively identifying a party.

Examples of authoritative party identifiers are GLN numbers, DUNS numbers, IBAN and SWIFT account numbers, and company registration and VAT numbers issued by national authorities.

Examples of non-authoritative party identifiers are email addresses issued by general email services such as Gmail and Hotmail.
PEPPOL: Pan-European Public Procurement Online. A Large Scale Pilot established to enable pan-European interoperability for public procurement. The PEPPOL infrastructure uses a four-cornered architecture to connect domains (private service providers and national public infrastructures).
http://www.peppol.eu
Peer-to-peer model: Two trading partners exchanging business documents directly with each other, and without the use of service providers or other intermediaries. In the peer-to-peer model, trading partners must bilaterally agree upon transport protocols and other standards involved.
Person: Not entirely automated system entity!
RR: DNS Resource Record, returned in response to a DNS query.
Service Metadata Locator: A common DNS registry in a BDXR architecture allowing gateways to locate metadata services of connected trading partners.
Service Metadata Publisher: A Service Metadata Publisher (or SMP) provides a standardized interface where gateways in a BDXR architecture can retrieve specific metadata about a connected trading partner and about the trading partner's gateway service. The term "metadata" is here used in its broadest and most general meaning, and metadata may contain information about anything from supported document types and business processes to specific information about transport protocols and technical endpoint addresses.
Service provider: The basic function of a service provider is to act as enabler and intermediary (or shared service) for trading partners who are exchanging business documents. A service provider operates the shared service used between trading partners in three-cornered architectures and the gateway service used in four-cornered architectures.
SML: Abbreviation for "Service Metadata Locator".
SMLP: Service Metadata Locator and Publisher. A multilayered capabilities and services discovery model involving Service Metadata Locators and Service Metadata Publishers.
SMP: Abbreviation for "Service Metadata Publisher".
Three-corner model: An architecture model where a central service (usually provided by a service provider) allows trading partners to exchange business documents. In the three-corner architecture, trading partners do not necessarily have to agree upon common standards as the service may provide translation and accommodate for different connectivity requirements, however a party can only exchange business documents with other parties connected to the same service.
Trading partner: A trading partner is an organization or legal entity that has a business relation with one or more other trading partners, and as part of their business relation needs to exchange business documents. Trading partners may exchange business documents through bilaterally agreed upon standards in a peer-to-peer model, through the use of a shared service in a three-corner model, or through gateway services in a four-corner model.