Difference between revisions of "FTSD-ConCalls-20081028"
Jump to navigation
Jump to search
WoodyBeeler (talk | contribs) |
|||
| Line 3: | Line 3: | ||
==Attendees== | ==Attendees== | ||
| − | + | Julian, Knight, Singureanu, Beeler, Rock, Mulrooney | |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | == | + | ==Actions== |
| + | #Approve previous meeting minutes September 30th 2008 - Unanimous | ||
| + | #Adopt Agenda - Unanimous | ||
| − | + | ==Discussion of "HL7 PING" Proposal== | |
| − | + | ===Proposal=== | |
| − | |||
In the Infrastructure and Messaging Q1 session on Wednesday, September 17, 2008, A motion was made by Rene Spronk, seconded by Mark Tucker, and passed by 10-0-0 to wit: | In the Infrastructure and Messaging Q1 session on Wednesday, September 17, 2008, A motion was made by Rene Spronk, seconded by Mark Tucker, and passed by 10-0-0 to wit: | ||
| − | "Infrastructure and Messaging(InM) has created a HL7 Ping artifact. InM recommends to the Technical Steering Committee(TSC), and to other relevant parties within HL7 that it support a policy decision that the HL7 Ping interaction SHALL be mandatorily supported by all applications that claim conformance to any part of the HL7 v3 messaging standard.” | + | :"Infrastructure and Messaging(InM) has created a HL7 Ping artifact. InM recommends to the Technical Steering Committee(TSC), and to other relevant parties within HL7 that it support a policy decision that the HL7 Ping interaction SHALL be mandatorily supported by all applications that claim conformance to any part of the HL7 v3 messaging standard.” |
| − | |||
| − | Reference: http://www.hl7.org/Library/Committees/Inm/20040827%5FHL7%5Fprop%5F908%2Edoc | + | InM therefore requests that this item be placed on the agenda for the steering division, and that upon passing the steering division, it be forwarded to the TSC for action. Reference: http://www.hl7.org/Library/Committees/Inm/20040827%5FHL7%5Fprop%5F908%2Edoc |
| + | |||
| + | '''Moved/Seconded''' Julian/Beeler (to get discussion on table) | ||
| + | |||
| + | ===Discussion=== | ||
| + | *Requirements arose under Shared Messages (MT) domain. Objectives are to discovery capability and to assure a receiving application is running. Initial requirement was for PING (apparently) with discovery added. | ||
| + | *Utility of the PING was challenged, and response was: | ||
| + | *#Is heavily useful in the arena of multiple routers and interface engines, where the identity and direct path to the responding application is masked by the intermediaries; and | ||
| + | *#When designed, it is not possible to know whether a given application will be used behind routers and relat4ed interface engines, therefore, to be useful, the PING must be mandated. | ||
| + | *What is the "state" of this interaction? Not yet balloted. Should it not be balloted and have the issue of mandatory part of the ballot, and/or undertaken after that event? | ||
| + | *General consensus that one should separate PING from discovery, as the latter has a variety of solutions (WSDL, registries, etc.) and is optional in the current proposal in any event. | ||
| + | *Believe that this should be an effort led by the Conformance and Implementation Work Group. | ||
| + | ===Vote=== | ||
| + | :For: Julian | ||
| + | :Against: Beeler, Mulrooney, Rock | ||
| + | :Abstain: Knight | ||
| + | ===Summary of negative and abstention reasons=== | ||
| + | These should be treated as the "negative comments" and addressed in future proposals. The numbers represent (approximate) number voicing a particular reason: | ||
| + | *Should separate PING from discovery (3); | ||
| + | *Not convinced that the PING is wrong, but question making it mandatory(2); | ||
| + | *This must be considered by the Conformance and Implementation Work Group (3); | ||
| + | *Backwards compatibility, makes existing implementations non-conformant (1). | ||
| + | |||
| + | ==Adjourned== | ||
| + | 11:30AM | ||
Latest revision as of 15:59, 28 October 2008
Contents
Foundation and Technology Steering Division Conference Call
FTSD - Foundation & Technology Steering Division
Attendees
Julian, Knight, Singureanu, Beeler, Rock, Mulrooney
Actions
- Approve previous meeting minutes September 30th 2008 - Unanimous
- Adopt Agenda - Unanimous
Discussion of "HL7 PING" Proposal
Proposal
In the Infrastructure and Messaging Q1 session on Wednesday, September 17, 2008, A motion was made by Rene Spronk, seconded by Mark Tucker, and passed by 10-0-0 to wit:
- "Infrastructure and Messaging(InM) has created a HL7 Ping artifact. InM recommends to the Technical Steering Committee(TSC), and to other relevant parties within HL7 that it support a policy decision that the HL7 Ping interaction SHALL be mandatorily supported by all applications that claim conformance to any part of the HL7 v3 messaging standard.”
InM therefore requests that this item be placed on the agenda for the steering division, and that upon passing the steering division, it be forwarded to the TSC for action. Reference: http://www.hl7.org/Library/Committees/Inm/20040827%5FHL7%5Fprop%5F908%2Edoc
Moved/Seconded Julian/Beeler (to get discussion on table)
Discussion
- Requirements arose under Shared Messages (MT) domain. Objectives are to discovery capability and to assure a receiving application is running. Initial requirement was for PING (apparently) with discovery added.
- Utility of the PING was challenged, and response was:
- Is heavily useful in the arena of multiple routers and interface engines, where the identity and direct path to the responding application is masked by the intermediaries; and
- When designed, it is not possible to know whether a given application will be used behind routers and relat4ed interface engines, therefore, to be useful, the PING must be mandated.
- What is the "state" of this interaction? Not yet balloted. Should it not be balloted and have the issue of mandatory part of the ballot, and/or undertaken after that event?
- General consensus that one should separate PING from discovery, as the latter has a variety of solutions (WSDL, registries, etc.) and is optional in the current proposal in any event.
- Believe that this should be an effort led by the Conformance and Implementation Work Group.
Vote
- For: Julian
- Against: Beeler, Mulrooney, Rock
- Abstain: Knight
Summary of negative and abstention reasons
These should be treated as the "negative comments" and addressed in future proposals. The numbers represent (approximate) number voicing a particular reason:
- Should separate PING from discovery (3);
- Not convinced that the PING is wrong, but question making it mandatory(2);
- This must be considered by the Conformance and Implementation Work Group (3);
- Backwards compatibility, makes existing implementations non-conformant (1).
Adjourned
11:30AM
