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

[Moberg Dale <dmoberg@axway.com>]

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.