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


Help: OASIS Mailing Lists Help | MarkMail Help

bdxr message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [bdxr] Use cases and a proposed "Connect" protocol

Dale: the text where you say “Roger writes” was actually pulled from Pim’s presentation, so I should defer to him on those questions (and also because of his greater technical expertise!)


I would, however, ask you to clarify your question as the “intent… to abandon the PEPPOL architectural separation between SML and SMP”?  Rather than eroding/abandoning this separation, it seems to me that we’re proposing here to introduce one or two additional layers of separation:

1.       Locator Service

2.       Connect Authorization Service (including Authentication)

3.       Connect Metadata/Profile (CPP) Query Service

4.       Connect Agreement (CPA) Creation Service


I may not have stated this quite right, but I think the basic points are:

a)      As with PEPPOL now, lookup of a service remains architecturally separate from what’s required to get details about, and connect to a service

b)      As distinct from PEPPOL now, step #3, obtaining the ‘Metadata’ aka ‘Profile’ of a service is here embedded as just one step in a protocol that now also includes (#2) pairwise mutual authorization, and (#4) creation of a collaboration agreement between the parties (via a more or less flexible negotiation protocol).


It’s unclear to me to what extent the Authorization service is cleanly separated from the Metadata/Profile handshaking – or if, conversely, the requester’s Profile would be presented as part of an Authorization Request.




From: bdxr@lists.oasis-open.org [mailto:bdxr@lists.oasis-open.org] On Behalf Of Moberg Dale
Sent: Monday, July 23, 2012 3:10 PM
To: Roger Bass; bdxr@lists.oasis-open.org
Subject: RE: [bdxr] Use cases and a proposed "Connect" protocol


I have a few questions concerning the functional requirements associated with the use cases that Roger is concerned with.


Roger writes” “Connect to a business partner using a message protocol: the registry would serve only to discover the endpoint for the “connect” message, not to retrieve an SMP or CPP


Dale> Is the endpoint to be retrieved a URL, or something else? What message protocols are to be used? For message protocols that are “layered” over an IETF application layer protocol (such as HTTP, FTP, SMTP, POP, XMPP, MSRP, etc.) how can different endpoints for different protocols be indicated? Or is the assumption that there is a single URL for all message protocols (for a given URL scheme, such as HTTP). DDDS can provide URI endpoint information for an arbitrary service (provided that the service has an agreed upon DDDS name!); can that serve as the underlying query-response technology ? If not, why not?


Is your intention in the above to abandon the PEPPOL architectural separation between SLP and SMP modules (in saying ‘not to retrieve an SMP or CPP)? What is the structure of the query “to the registry” – or is the query protocol being identified with the “Connect” protocol?


What forms are allowed for “registries”? DNS, LDAP, RegRep, UDDI, etc. Or something new?


Roger continues: Services to be considered


·         Authorize an identified party (possibly for some subset of services)

·         Obtain profile information from a party (capabilities and/or delivery channels)

·         Provide profile information to a party

·         Publish profile updates to a party

·         Create/terminate a named agreement


Dale> (Are all of the above bulleted services to be provided by the” Connect protocol”? Or does each service use the same  endpoint information that the Connect protocol finds?  How does the request indicate what service is being requested? Are these services to work no matter what “message protocol” is being used?


What formats  are to be supported for response information?


What authorization protocol(s) are to be supported? SAML authz request/response? OAuth? Basic Auth?  Others? Something new (I hope that “something new” is out of scope for us.)


Is the general idea of the Connect protocol to invent or re-invent all these services and protocols? Or instead to “profile” how existing approaches can be applied to these probems?

Or something else? If we do something new, I hope it can somehow be meshed with what already exists somehow.


I think I need to understand a little better the scope of effort involved in creating the “Connect” protocol -- especially with respect to reuse of existing standards, customization of existing standards, or creation of new protocols and data formats.


Thanks Roger for starting this discussion.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]