OASIS Business Document Exchange (BDXR) TC

Expand all | Collapse all

e-CODEX use cases and requirements

  • 1.  e-CODEX use cases and requirements

    Posted 05-14-2012 10:12
      |   view attached
    Dear TC,   Please find attached a first impression of the use cases and requirements from the e-CODEX project ( www.e-codex.eu ). Since the requirements are, at this level, very similar to the ones from PEPPOL, I have referenced Kenneth's presentation and added the e-CODEX viewpoint for better comparability.   Best regards   Susanne     Attachment: e-CODEX_UseCases_Requirements.doc Description: e-CODEX_UseCases_Requirements.doc

    Attachment(s)



  • 2.  Generalizing metadata service discovery mechanism using DNS capabilities

    Posted 05-14-2012 14:26
      Please find attached a proposal on a way to discover a URL for a service that could provide connectivity capability ( metadata)   for  internet accessible “X2X “  interactions.   Some of the underlying standards may not be familiar, and if you have time,  here are some background links   http://en.wikipedia.org/wiki/NAPTR_record   An early application in the commercial supply chain (“internet of things”)  (now being updated to the “FONS” standard)   http://www.gs1.org/gsmp/kc/epcglobal/ons/ons_1_0_1-standard-20080529.pdf   Dale Moberg           Attachment: Generalizing SML Format approach.odp Description: Generalizing SML Format approach.odp


  • 3.  Error in the published charter

    Posted 05-14-2012 23:22
    Dear TC, I noticed that in the published TC charter the last section Liaisons is missing, this has to be fixed.  This can be easily verified comparing the currently published charter here:  http://www.oasis-open.org/committees/bdxr/charter.php  with the rechartering proposal that has been formally voted and approved, published here:  http://wiki.oasis-open.org/bdx/Recharter Best regards Andrea Caccia


  • 4.  Re: [bdxr] Error in the published charter

    Posted 05-15-2012 05:28
    Dear Andrea Per request from OASIS the Liaisons section was moved to the non-normative part of the TC rechartering proposal. Please see attached. Best regards, Kenneth From: Andrea Caccia < andrea.caccia@studiocaccia.com > Date: Monday, May 14, 2012 6:21 PM To: < bdxr@lists.oasis-open.org > Subject: [bdxr] Error in the published charter Dear TC, I noticed that in the published TC charter the last section Liaisons is missing, this has to be fixed.  This can be easily verified comparing the currently published charter here:  http://www.oasis-open.org/committees/bdxr/charter.php  with the rechartering proposal that has been formally voted and approved, published here:  http://wiki.oasis-open.org/bdx/Recharter Best regards Andrea Caccia ---  Begin Message  --- From : Chet Ensign <chet.ensign@oasis-open.org> To : Kenneth Bengtsson <kenneth@alfa1lab.com>, bdx@lists.oasis-open.org Date : Thu, 12 Apr 2012 11:30:33 -0400 Hi Kenneth, Here are the revisions I would like you to make to the submission. So that I have everything in one communication, would you put a note at the beginning stating that the TC approved requesting a Special Majority Ballot to approve its revised charter in its meeting of <date> and provide a link to those minutes. I know that you gave me that elsewhere, it will just make life simpler if I have everything in one place. Please move the paragraph labelled "Liaisons:" to the non-normative section of the submission. Please put that in the "Similar or applicable work:" section. You can add it as a second paragraph. Regarding the First meeting - I believe GoToMeeting always provides a call in number for those that can't access the over the Internet. While this will sound a bit crazy in this day and age, there are companies (such as Bloomberg LP, the last place I worked) that don't allow employees to use web meeting software or even Skype! So please add a sentence saying something like "A conference calling number will be available for any participants who cannot access the meeting online" to make sure the meeting is inclusive. On the list of members supporting rechartering, as you are an individual member, your affiliation needs to be "Individual member" not Alfa1lab. You will need an org statement of support from Difi-Agency or, alternately, remove Klaus from the list. You need to add "Name of the Convener:" as the last section. I am assuming that you are acting as convener so you can just copy your information there. That's it. I'll start setting up the ballot now so it can get launched right away. -- /chet ---------------- Chet Ensign Director of Standards Development and TC Administration OASIS: Advancing open standards for the information society http://www.oasis-open.org Primary: +1 973-996-2298 Mobile: +1 201-341-1393 Follow OASIS on: LinkedIn:     http://linkd.in/OASISopen Twitter:         http://twitter.com/OASISopen Facebook:   http://facebook.com/oasis.open --------------------------------------------------------------------- To unsubscribe, e-mail: bdx-unsubscribe@lists.oasis-open.org For additional commands, e-mail: bdx-help@lists.oasis-open.org ---  End Message  --- ---  Begin Message  --- From : Kenneth Bengtsson <kenneth@alfa1lab.com> To : Chet Ensign <chet.ensign@oasis-open.org> Date : Thu, 12 Apr 2012 10:59:49 -0500 Dear TC Admin To move the work of the OASIS Business Document Exchange (BDX) Technical Committee into a broader scope and to accommodate requirements raised by BDX adopters, the TC has decided to formally propose the new Charter below. The decision to submit the new charter and to commence the formal rechartering process was taken at the TC's meeting on March 14 2012 and recorded in the minutes of that meeting. The minutes are available here: http://www.oasis-open.org/apps/org/workgroup/bdx/document.php?document_id=4 5438 Name of the TC: OASIS Business Document Exchange TC Statement of Purpose: The BDX standard will describe an architecture (or sets of reference architectures) where two entities exchange business documents in a secure and reliable way through the use of gateways (sometimes also referred to as access points), which is also known as the "four-corner model". The purpose of the TC is therefore to define the specifications of a lightweight and federated messaging and trust infrastructure for reliable data exchange, messaging and web services interoperability between domains. Here, a "domain" can be any community whose members (a) are connected through a shared system, and (b) may interact with others across domains. Regardless of each domain's internal workings, such interactions entail them each consuming and exposing to others over the Internet certain interfaces. These specifications should provide a framework for domains to interoperate securely and reliably (via Web Services), which can therefore be viewed as an Inter-cloud Web Services framework. The TC specifications should be lightweight but, wherever and to the extent possible, based on profiles of existing standards from OASIS and elsewhere that are widely-used and proven, or otherwise seen to be generally applicable. Approaches that are modular and agnostic about data content and implementation architectures will be preferred. The TC will focus first on requirements for exchanges between groups of related domains around standardized processes/data. Requirements of cross-domain business documents exchange, with its corresponding use cases, and implied interoperability requirements will inform prioritization of the TC's initial deliverables. The TC will specifically address requirements submitted by the Large Scale Pilots ("LSPs") in the area of e-government PEPPOL and e-CODEX. The work of the TC will contribute to the ongoing convergence of Pan-European messaging and trust infrastructures for reliable data exchange. In certain areas the work will therefore initially be centered on the work of these LSPs (notably on SMLP around identity and service discovery, addressing and profiling), and will also consider other approaches and related specifications (e.g. DNS, ebXML CPA, UDDI, ebXML RegRep, WS-Discovery), The TC may define or profile more than one such specification(s). In other areas, published specifications today may be absent or have gaps. In such cases the TC will attempt to identify relevant standards or work-in-progress at OASIS or other SDOs to establish liaisons with and provide requirements for such efforts, as needed. Scope of work of the TC: The specific objectives will be to define, specify and maintain the following: 1. Use cases and requirements, based on submissions; 2. Profiling / gap analysis of existing standards with reference to the use cases and requirements, potentially including: a) Addressing / Routing / Discovery (SML and related technologies) b) Service profiles/Capabilities (SMP, CPA and others) c) Identity/Authentication d) Trust Frameworks e) Transport / Reliable Messaging (e.g. AS4) 3. Unified architecture for all processes necessary and sufficient for the superset of supported use cases; 4. Specifications for SML/SMP will be developed within the TC; 5. PEPPOL specifications for the START and LIME protocols. List of deliverables: Technical specifications for protocols supporting distributed discovery of locations and e-business and technical capabilities of exchange partners. Profiles of B2B messaging protocols for use in four-corner (or multi-corner) topologies. IPR Mode under which the TC will operate: The TC will operate under the Non-Assertion Mode. The anticipated audience or users of the work: The initial target groups for the TC are: - Enterprise procurement vendors and supplier networks - Software companies (e.g. providers of middleware and business applications) - Supplier information management providers - Public institutions - Financial institutions and payment networks - Large private companies Language of the Technical Committee: The business of the Technical Committee will be conducted in English. Non-normative information regarding the rechartering of the TC: Similar or applicable work: There are OASIS TC's and other standards bodies covering topics related to the BDX TC: ebMS, ebXML CPA, UDDI, ebXML RegRep, WS-Discovery, AMQP and ETSI REM. The BDX TC is not competing with any of these existing standards but will build upon their existing specifications to define a complete infrastructure architecture. Liaisons: The initial list of liaisons that will be established includes: OASIS ebXML Technical Committees, ETSI ESI and OASIS Identity in the Cloud TC. Other liaisons will be established in the course of the work. First meeting: First meeting of the rechartered TC will be held May 2nd 2012 at 16.00 CEST. The meeting will be held online. Access to the meeting is provided through https://www4.gotomeeting.com/join/925073807 . A conference calling number will be available for any participants who cannot access the meeting online. Meeting schedule: The TC will hold weekly conference calls and in addition two face-to-face meetings a year (November and May). Face-to-face meetings will be sponsored by the members of the TC. Members supporting the rechartering of the TC: Kenneth Bengtsson, kenneth@alfa1lab.com, individual member Mikkel Hippe Brun, mhb@tradeshift.com, Tradeshift Network Ltd. Andrea Caccia, andrea.caccia@studiocaccia.com, AITI-Associazione Italiana Tesorieri de Impresa Pim van der Eijk, pvde@sonnenglanz.net, Sonnenglanz Consulting Tim McGrath, tim.mcgrath@documentengineeringservices.com, Document Engineering Services Limited Sven Rasmussen, svrr@itst.dk, Denmark Ministry of Science, Technology & Innovation / DIGST Susanne Wigaard, Susanne.Wigard@it.nrw.de, Land Nordrhein-Westfalen Organizational members' statements of support: Document Engineering Services Limited: "Having been a supporter of the original Business Document Exchange TC's charter, Document Engineering Services fully supports the rechartering of the BDX TC as proposed." Sonnenglanz Consulting: "Sonnenglanz Consulting supports the proposed rechartering of the BDX TC, as agreed in the BDX TC meeting of March 14th and recorded in the minutes http://www.oasis-open.org/apps/org/workgroup/bdx/document.php?document_id=4 5438 < http://www.oasis-open.org/apps/org/workgroup/bdx/document.php?document_id= 45438.>." Land Nordrhein-Westfalen: "The Land Nordrhein-Westfalen supports the proposed rechartering of the BDX TC." AITI-Associazione Italiana Tesorieri de Impresa: "AITI too supports the rechartering." Denmark Ministry of Science, Technology & Innovation / DIGST: "NITA/DIGST also supports the proposed rechartering of the BDX TC, as agreed in the BDX TC meeting of March 14th and recorded in the minutes http://www.oasis-open.org/apps/org/workgroup/bdx/document.php?document_id=4 5438 < http://www.oasis-open.org/apps/org/workgroup/bdx/document.php?document_id= 45438.>." Tradeshift Networks Ltd.: "Tradeshift supports the proposed rechartering of the BDX TC, as agreed in the BDX TC meeting of March 14th and recorded in the minutes http://www.oasis-open.org/apps/org/workgroup/bdx/document.php?document_id=4 5438 < http://www.oasis-open.org/apps/org/workgroup/bdx/document.php?document_id= 45438.>." Name of the Convener: The Convener is Kenneth Bengtsson, kenneth@alfa1lab.com --------------------------------------------------------------------- To unsubscribe, e-mail: bdx-unsubscribe@lists.oasis-open.org For additional commands, e-mail: bdx-help@lists.oasis-open.org ---  End Message  ---


  • 5.  Re: [bdxr] Error in the published charter

    Posted 05-15-2012 13:50
    Kenneth, Andrea - Can I suggest that you can put the Liaisons material on the TC's main web page? That would make it even more evident than on the charter page. /chet On Tue, May 15, 2012 at 1:27 AM, Kenneth Bengtsson <kenneth@alfa1lab.com> wrote: > Dear Andrea > > Per request from OASIS the "Liaisons" section was moved to the non-normative > part of the TC rechartering proposal. Please see attached. > > Best regards, > > Kenneth > > > From: Andrea Caccia <andrea.caccia@studiocaccia.com> > Date: Monday, May 14, 2012 6:21 PM > To: <bdxr@lists.oasis-open.org> > Subject: [bdxr] Error in the published charter > > Dear TC, > I noticed that in the published TC charter the last section "Liaisons" is > missing, this has to be fixed. > This can be easily verified comparing the currently published charter > here:  http://www.oasis-open.org/committees/bdxr/charter.php with the > rechartering proposal that has been formally voted and approved, published > here:  http://wiki.oasis-open.org/bdx/Recharter > > Best regards > Andrea Caccia > > > ---------- Forwarded message ---------- > From: Chet Ensign <chet.ensign@oasis-open.org> > To: Kenneth Bengtsson <kenneth@alfa1lab.com>, bdx@lists.oasis-open.org > Cc: > Date: Thu, 12 Apr 2012 11:30:33 -0400 > Subject: [bdx] Revisions to the submitted revised charter > Hi Kenneth, > > Here are the revisions I would like you to make to the submission. > > So that I have everything in one communication, would you put a note > at the beginning stating that the TC approved requesting a Special > Majority Ballot to approve its revised charter in its meeting of > <date> and provide a link to those minutes. I know that you gave me > that elsewhere, it will just make life simpler if I have everything in > one place. > > Please move the paragraph labelled "Liaisons:" to the non-normative > section of the submission. Please put that in the "Similar or > applicable work:" section. You can add it as a second paragraph. > > Regarding the First meeting - I believe GoToMeeting always provides a > call in number for those that can't access the over the Internet. > While this will sound a bit crazy in this day and age, there are > companies (such as Bloomberg LP, the last place I worked) that don't > allow employees to use web meeting software or even Skype! So please > add a sentence saying something like "A conference calling number will > be available for any participants who cannot access the meeting > online" to make sure the meeting is inclusive. > > On the list of members supporting rechartering, as you are an > individual member, your affiliation needs to be "Individual member" > not Alfa1lab. > > You will need an org statement of support from Difi-Agency or, > alternately, remove Klaus from the list. > > You need to add "Name of the Convener:" as the last section. I am > assuming that you are acting as convener so you can just copy your > information there. > > That's it. I'll start setting up the ballot now so it can get launched > right away. > > -- > > /chet > ---------------- > Chet Ensign > Director of Standards Development and TC Administration > OASIS: Advancing open standards for the information society > http://www.oasis-open.org > > Primary: +1 973-996-2298 > Mobile: +1 201-341-1393 > > Follow OASIS on: > LinkedIn:     http://linkd.in/OASISopen > Twitter:         http://twitter.com/OASISopen > Facebook:   http://facebook.com/oasis.open > > --------------------------------------------------------------------- > To unsubscribe, e-mail: bdx-unsubscribe@lists.oasis-open.org > For additional commands, e-mail: bdx-help@lists.oasis-open.org > > > > ---------- Forwarded message ---------- > From: Kenneth Bengtsson <kenneth@alfa1lab.com> > To: Chet Ensign <chet.ensign@oasis-open.org> > Cc: "bdx@lists.oasis-open.org" <bdx@lists.oasis-open.org> > Date: Thu, 12 Apr 2012 10:59:49 -0500 > Subject: [bdx] OASIS Business Document Exchange (BDX) Technical Committee > rechartering > Dear TC Admin > > To move the work of the OASIS Business Document Exchange (BDX) Technical > Committee into a broader scope and to accommodate requirements raised by > BDX adopters, the TC has decided to formally propose the new Charter > below. The decision to submit the new charter and to commence the formal > rechartering process was taken at the TC's meeting on March 14 2012 and > recorded in the minutes of that meeting. The minutes are available here: > > http://www.oasis-open.org/apps/org/workgroup/bdx/document.php?document_id=4 > 5438 > > > > Name of the TC: > OASIS Business Document Exchange TC > > Statement of Purpose: > The BDX standard will describe an architecture (or sets of reference > architectures) where two entities exchange business documents in a secure > and reliable way through the use of gateways (sometimes also referred to > as access points), which is also known as the "four-corner model". > > The purpose of the TC is therefore to define the specifications of a > lightweight and federated messaging and trust infrastructure for reliable > data exchange, messaging and web services interoperability between > domains. Here, a "domain" can be any community whose members (a) are > connected through a shared system, and (b) may interact with others across > domains. > > Regardless of each domain's internal workings, such interactions entail > them each consuming and exposing to others over the Internet certain > interfaces. These specifications should provide a framework for domains to > interoperate securely and reliably (via Web Services), which can therefore > be viewed as an Inter-cloud Web Services framework. > > The TC specifications should be lightweight but, wherever and to the > extent possible, based on profiles of existing standards from OASIS and > elsewhere that are widely-used and proven, or otherwise seen to be > generally applicable. Approaches that are modular and agnostic about data > content and implementation architectures will be preferred. > > The TC will focus first on requirements for exchanges between groups of > related domains around standardized processes/data. Requirements of > cross-domain business documents exchange, with its corresponding use > cases, and implied interoperability requirements will inform > prioritization of the TC's initial deliverables. The TC will specifically > address requirements submitted by the Large Scale Pilots ("LSPs") in the > area of e-government PEPPOL and e-CODEX. The work of the TC will > contribute to the ongoing convergence of Pan-European messaging and trust > infrastructures for reliable data exchange. > > In certain areas the work will therefore initially be centered on the work > of these LSPs (notably on SMLP around identity and service discovery, > addressing and profiling), and will also consider other approaches and > related specifications (e.g. DNS, ebXML CPA, UDDI, ebXML RegRep, > WS-Discovery), The TC may define or profile more than one such > specification(s). > > In other areas, published specifications today may be absent or have gaps. > In such cases the TC will attempt to identify relevant standards or > work-in-progress at OASIS or other SDOs to establish liaisons with and > provide requirements for such efforts, as needed. > > Scope of work of the TC: > The specific objectives will be to define, specify and maintain the > following: > > 1. Use cases and requirements, based on submissions; > 2. Profiling / gap analysis of existing standards with reference to the > use cases and requirements, potentially including: >  a) Addressing / Routing / Discovery (SML and related technologies) >  b) Service profiles/Capabilities (SMP, CPA and others) >  c) Identity/Authentication >  d) Trust Frameworks >  e) Transport / Reliable Messaging (e.g. AS4) > 3. Unified architecture for all processes necessary and sufficient for the > superset of supported use cases; > 4. Specifications for SML/SMP will be developed within the TC; > 5. PEPPOL specifications for the START and LIME protocols. > > List of deliverables: > Technical specifications for protocols supporting distributed discovery of > locations and e-business and technical capabilities of exchange partners. > > Profiles of B2B messaging protocols for use in four-corner (or > multi-corner) topologies. > > IPR Mode under which the TC will operate: > The TC will operate under the Non-Assertion Mode. > > The anticipated audience or users of the work: > The initial target groups for the TC are: > > - Enterprise procurement vendors and supplier networks > - Software companies (e.g. providers of middleware and business > applications) > - Supplier information management providers > - Public institutions > - Financial institutions and payment networks > - Large private companies > > Language of the Technical Committee: > The business of the Technical Committee will be conducted in English. > > > Non-normative information regarding the rechartering of the TC: > > Similar or applicable work: > There are OASIS TC's and other standards bodies covering topics related to > the BDX TC: ebMS, ebXML CPA, UDDI, ebXML RegRep, WS-Discovery, AMQP and > ETSI REM. The BDX TC is not competing with any of these existing standards > but will build upon their existing specifications to define a complete > infrastructure architecture. > > Liaisons: The initial list of liaisons that will be established includes: > OASIS ebXML Technical Committees, ETSI ESI and OASIS Identity in the Cloud > TC. Other liaisons will be established in the course of the work. > > > First meeting: > First meeting of the rechartered TC will be held May 2nd 2012 at 16.00 > CEST. The meeting will be held online. Access to the meeting is provided > through https://www4.gotomeeting.com/join/925073807 . A conference calling > number will be available for any participants who cannot access the > meeting online. > > > Meeting schedule: > The TC will hold weekly conference calls and in addition two face-to-face > meetings a year (November and May). Face-to-face meetings will be > sponsored by the members of the TC. > > Members supporting the rechartering of the TC: > Kenneth Bengtsson, kenneth@alfa1lab.com, individual member > Mikkel Hippe Brun, mhb@tradeshift.com, Tradeshift Network Ltd. > Andrea Caccia, andrea.caccia@studiocaccia.com, AITI-Associazione Italiana > Tesorieri de Impresa > Pim van der Eijk, pvde@sonnenglanz.net, Sonnenglanz Consulting > Tim McGrath, tim.mcgrath@documentengineeringservices.com, Document > Engineering Services Limited > Sven Rasmussen, svrr@itst.dk, Denmark Ministry of Science, Technology & > Innovation / DIGST > Susanne Wigaard, Susanne.Wigard@it.nrw.de, Land Nordrhein-Westfalen > > Organizational members' statements of support: > Document Engineering Services Limited: > "Having been a supporter of the original Business Document Exchange TC's > charter, Document Engineering Services fully supports the rechartering of > the BDX TC as proposed." > > Sonnenglanz Consulting: > "Sonnenglanz Consulting supports the proposed rechartering of the BDX TC, > as agreed in the BDX TC meeting of March 14th and recorded in the minutes > http://www.oasis-open.org/apps/org/workgroup/bdx/document.php?document_id=4 > 5438 > < http://www.oasis-open.org/apps/org/workgroup/bdx/document.php?document_id= > 45438.>." > > Land Nordrhein-Westfalen: > "The Land Nordrhein-Westfalen supports the proposed rechartering of the > BDX TC." > > AITI-Associazione Italiana Tesorieri de Impresa: > "AITI too supports the rechartering." > > Denmark Ministry of Science, Technology & Innovation / DIGST: > "NITA/DIGST also supports the proposed rechartering of the BDX TC, as > agreed in the BDX TC meeting of March 14th and recorded in the minutes > http://www.oasis-open.org/apps/org/workgroup/bdx/document.php?document_id=4 > 5438 > < http://www.oasis-open.org/apps/org/workgroup/bdx/document.php?document_id= > 45438.>." > > Tradeshift Networks Ltd.: > "Tradeshift supports the proposed rechartering of the BDX TC, as agreed in > the BDX TC meeting of March 14th and recorded in the minutes > http://www.oasis-open.org/apps/org/workgroup/bdx/document.php?document_id=4 > 5438 > < http://www.oasis-open.org/apps/org/workgroup/bdx/document.php?document_id= > 45438.>." > > Name of the Convener: > > The Convener is Kenneth Bengtsson, kenneth@alfa1lab.com > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: bdx-unsubscribe@lists.oasis-open.org > For additional commands, e-mail: bdx-help@lists.oasis-open.org > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: bdxr-unsubscribe@lists.oasis-open.org > For additional commands, e-mail: bdxr-help@lists.oasis-open.org -- /chet ---------------- Chet Ensign Director of Standards Development and TC Administration OASIS: Advancing open standards for the information society http://www.oasis-open.org Primary: +1 973-996-2298 Mobile: +1 201-341-1393 Follow OASIS on: LinkedIn:     http://linkd.in/OASISopen Twitter:         http://twitter.com/OASISopen Facebook:   http://facebook.com/oasis.open


  • 6.  Re: [bdxr] Error in the published charter

    Posted 05-15-2012 14:39
    Just spotted this flying across the radar... > Liaisons material on the TC's main web page Yes: as described in policy and template for home hage 1.  Liaisons to a Technical Committee or Member Section "... the liaison must be listed on the web page of the TC" http://www.oasis-open.org/policies-guidelines/liaison#tcliaison 2.  The "TC Liaisons" should be listed after Subcommittees  on theBDXR TC home page; see: TC Public Page Template   XHTML Template (.html)   Template Instructions   http://docs.oasis-open.org/templates/TCPublicPageTemplate.htm Model: Table of Contents  Announcements  Overview  Subcommittees  TC Liaisons <--************  Technical Work Produced by the Committee  Expository Work Produced by the Committee  External Resources  Mailing Lists and Comments  Additional Information  see: from "Templates" http://docs.oasis-open.org/templates/ On Tue, May 15, 2012 at 8:50 AM, Chet Ensign < chet.ensign@oasis-open.org > wrote: Kenneth, Andrea - Can I suggest that you can put the Liaisons material on the TC's main web page? That would make it even more evident than on the charter page. /chet On Tue, May 15, 2012 at 1:27 AM, Kenneth Bengtsson < kenneth@alfa1lab.com > wrote: > Dear Andrea > > Per request from OASIS the "Liaisons" section was moved to the non-normative > part of the TC rechartering proposal. Please see attached. > > Best regards, > > Kenneth > > > From: Andrea Caccia < andrea.caccia@studiocaccia.com > > Date: Monday, May 14, 2012 6:21 PM > To: < bdxr@lists.oasis-open.org > > Subject: [bdxr] Error in the published charter > > Dear TC, > I noticed that in the published TC charter the last section "Liaisons" is > missing, this has to be fixed. > This can be easily verified comparing the currently published charter > here:  http://www.oasis-open.org/committees/bdxr/charter.php  with the > rechartering proposal that has been formally voted and approved, published > here:  http://wiki.oasis-open.org/bdx/Recharter > > Best regards > Andrea Caccia > > > ---------- Forwarded message ---------- > From: Chet Ensign < chet.ensign@oasis-open.org > > To: Kenneth Bengtsson < kenneth@alfa1lab.com >, bdx@lists.oasis-open.org > Cc: > Date: Thu, 12 Apr 2012 11:30:33 -0400 > Subject: [bdx] Revisions to the submitted revised charter > Hi Kenneth, > > Here are the revisions I would like you to make to the submission. > > So that I have everything in one communication, would you put a note > at the beginning stating that the TC approved requesting a Special > Majority Ballot to approve its revised charter in its meeting of > <date> and provide a link to those minutes. I know that you gave me > that elsewhere, it will just make life simpler if I have everything in > one place. > > Please move the paragraph labelled "Liaisons:" to the non-normative > section of the submission. Please put that in the "Similar or > applicable work:" section. You can add it as a second paragraph. > > Regarding the First meeting - I believe GoToMeeting always provides a > call in number for those that can't access the over the Internet. > While this will sound a bit crazy in this day and age, there are > companies (such as Bloomberg LP, the last place I worked) that don't > allow employees to use web meeting software or even Skype! So please > add a sentence saying something like "A conference calling number will > be available for any participants who cannot access the meeting > online" to make sure the meeting is inclusive. > > On the list of members supporting rechartering, as you are an > individual member, your affiliation needs to be "Individual member" > not Alfa1lab. > > You will need an org statement of support from Difi-Agency or, > alternately, remove Klaus from the list. > > You need to add "Name of the Convener:" as the last section. I am > assuming that you are acting as convener so you can just copy your > information there. > > That's it. I'll start setting up the ballot now so it can get launched > right away. > > -- > > /chet > ---------------- > Chet Ensign > Director of Standards Development and TC Administration > OASIS: Advancing open standards for the information society > http://www.oasis-open.org > > Primary: +1 973-996-2298 > Mobile: +1 201-341-1393 > > Follow OASIS on: > LinkedIn:     http://linkd.in/OASISopen > Twitter:         http://twitter.com/OASISopen > Facebook:   http://facebook.com/oasis.open > > --------------------------------------------------------------------- > To unsubscribe, e-mail: bdx-unsubscribe@lists.oasis-open.org > For additional commands, e-mail: bdx-help@lists.oasis-open.org > > > > ---------- Forwarded message ---------- > From: Kenneth Bengtsson < kenneth@alfa1lab.com > > To: Chet Ensign < chet.ensign@oasis-open.org > > Cc: " bdx@lists.oasis-open.org " < bdx@lists.oasis-open.org > > Date: Thu, 12 Apr 2012 10:59:49 -0500 > Subject: [bdx] OASIS Business Document Exchange (BDX) Technical Committee > rechartering > Dear TC Admin > > To move the work of the OASIS Business Document Exchange (BDX) Technical > Committee into a broader scope and to accommodate requirements raised by > BDX adopters, the TC has decided to formally propose the new Charter > below. The decision to submit the new charter and to commence the formal > rechartering process was taken at the TC's meeting on March 14 2012 and > recorded in the minutes of that meeting. The minutes are available here: > > http://www.oasis-open.org/apps/org/workgroup/bdx/document.php?document_id=4 > 5438 > > > > Name of the TC: > OASIS Business Document Exchange TC > > Statement of Purpose: > The BDX standard will describe an architecture (or sets of reference > architectures) where two entities exchange business documents in a secure > and reliable way through the use of gateways (sometimes also referred to > as access points), which is also known as the "four-corner model". > > The purpose of the TC is therefore to define the specifications of a > lightweight and federated messaging and trust infrastructure for reliable > data exchange, messaging and web services interoperability between > domains. Here, a "domain" can be any community whose members (a) are > connected through a shared system, and (b) may interact with others across > domains. > > Regardless of each domain's internal workings, such interactions entail > them each consuming and exposing to others over the Internet certain > interfaces. These specifications should provide a framework for domains to > interoperate securely and reliably (via Web Services), which can therefore > be viewed as an Inter-cloud Web Services framework. > > The TC specifications should be lightweight but, wherever and to the > extent possible, based on profiles of existing standards from OASIS and > elsewhere that are widely-used and proven, or otherwise seen to be > generally applicable. Approaches that are modular and agnostic about data > content and implementation architectures will be preferred. > > The TC will focus first on requirements for exchanges between groups of > related domains around standardized processes/data. Requirements of > cross-domain business documents exchange, with its corresponding use > cases, and implied interoperability requirements will inform > prioritization of the TC's initial deliverables. The TC will specifically > address requirements submitted by the Large Scale Pilots ("LSPs") in the > area of e-government PEPPOL and e-CODEX. The work of the TC will > contribute to the ongoing convergence of Pan-European messaging and trust > infrastructures for reliable data exchange. > > In certain areas the work will therefore initially be centered on the work > of these LSPs (notably on SMLP around identity and service discovery, > addressing and profiling), and will also consider other approaches and > related specifications (e.g. DNS, ebXML CPA, UDDI, ebXML RegRep, > WS-Discovery), The TC may define or profile more than one such > specification(s). > > In other areas, published specifications today may be absent or have gaps. > In such cases the TC will attempt to identify relevant standards or > work-in-progress at OASIS or other SDOs to establish liaisons with and > provide requirements for such efforts, as needed. > > Scope of work of the TC: > The specific objectives will be to define, specify and maintain the > following: > > 1. Use cases and requirements, based on submissions; > 2. Profiling / gap analysis of existing standards with reference to the > use cases and requirements, potentially including: >  a) Addressing / Routing / Discovery (SML and related technologies) >  b) Service profiles/Capabilities (SMP, CPA and others) >  c) Identity/Authentication >  d) Trust Frameworks >  e) Transport / Reliable Messaging (e.g. AS4) > 3. Unified architecture for all processes necessary and sufficient for the > superset of supported use cases; > 4. Specifications for SML/SMP will be developed within the TC; > 5. PEPPOL specifications for the START and LIME protocols. > > List of deliverables: > Technical specifications for protocols supporting distributed discovery of > locations and e-business and technical capabilities of exchange partners. > > Profiles of B2B messaging protocols for use in four-corner (or > multi-corner) topologies. > > IPR Mode under which the TC will operate: > The TC will operate under the Non-Assertion Mode. > > The anticipated audience or users of the work: > The initial target groups for the TC are: > > - Enterprise procurement vendors and supplier networks > - Software companies (e.g. providers of middleware and business > applications) > - Supplier information management providers > - Public institutions > - Financial institutions and payment networks > - Large private companies > > Language of the Technical Committee: > The business of the Technical Committee will be conducted in English. > > > Non-normative information regarding the rechartering of the TC: > > Similar or applicable work: > There are OASIS TC's and other standards bodies covering topics related to > the BDX TC: ebMS, ebXML CPA, UDDI, ebXML RegRep, WS-Discovery, AMQP and > ETSI REM. The BDX TC is not competing with any of these existing standards > but will build upon their existing specifications to define a complete > infrastructure architecture. > > Liaisons: The initial list of liaisons that will be established includes: > OASIS ebXML Technical Committees, ETSI ESI and OASIS Identity in the Cloud > TC. Other liaisons will be established in the course of the work. > > > First meeting: > First meeting of the rechartered TC will be held May 2nd 2012 at 16.00 > CEST. The meeting will be held online. Access to the meeting is provided > through https://www4.gotomeeting.com/join/925073807 . A conference calling > number will be available for any participants who cannot access the > meeting online. > > > Meeting schedule: > The TC will hold weekly conference calls and in addition two face-to-face > meetings a year (November and May). Face-to-face meetings will be > sponsored by the members of the TC. > > Members supporting the rechartering of the TC: > Kenneth Bengtsson, kenneth@alfa1lab.com , individual member > Mikkel Hippe Brun, mhb@tradeshift.com , Tradeshift Network Ltd. > Andrea Caccia, andrea.caccia@studiocaccia.com , AITI-Associazione Italiana > Tesorieri de Impresa > Pim van der Eijk, pvde@sonnenglanz.net , Sonnenglanz Consulting > Tim McGrath, tim.mcgrath@documentengineeringservices.com , Document > Engineering Services Limited > Sven Rasmussen, svrr@itst.dk , Denmark Ministry of Science, Technology & > Innovation / DIGST > Susanne Wigaard, Susanne.Wigard@it.nrw.de , Land Nordrhein-Westfalen > > Organizational members' statements of support: > Document Engineering Services Limited: > "Having been a supporter of the original Business Document Exchange TC's > charter, Document Engineering Services fully supports the rechartering of > the BDX TC as proposed." > > Sonnenglanz Consulting: > "Sonnenglanz Consulting supports the proposed rechartering of the BDX TC, > as agreed in the BDX TC meeting of March 14th and recorded in the minutes > http://www.oasis-open.org/apps/org/workgroup/bdx/document.php?document_id=4 > 5438 > < http://www.oasis-open.org/apps/org/workgroup/bdx/document.php?document_id= > 45438.>." > > Land Nordrhein-Westfalen: > "The Land Nordrhein-Westfalen supports the proposed rechartering of the > BDX TC." > > AITI-Associazione Italiana Tesorieri de Impresa: > "AITI too supports the rechartering." > > Denmark Ministry of Science, Technology & Innovation / DIGST: > "NITA/DIGST also supports the proposed rechartering of the BDX TC, as > agreed in the BDX TC meeting of March 14th and recorded in the minutes > http://www.oasis-open.org/apps/org/workgroup/bdx/document.php?document_id=4 > 5438 > < http://www.oasis-open.org/apps/org/workgroup/bdx/document.php?document_id= > 45438.>." > > Tradeshift Networks Ltd.: > "Tradeshift supports the proposed rechartering of the BDX TC, as agreed in > the BDX TC meeting of March 14th and recorded in the minutes > http://www.oasis-open.org/apps/org/workgroup/bdx/document.php?document_id=4 > 5438 > < http://www.oasis-open.org/apps/org/workgroup/bdx/document.php?document_id= > 45438.>." > > Name of the Convener: > > The Convener is Kenneth Bengtsson, kenneth@alfa1lab.com > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: bdx-unsubscribe@lists.oasis-open.org > For additional commands, e-mail: bdx-help@lists.oasis-open.org > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: bdxr-unsubscribe@lists.oasis-open.org > For additional commands, e-mail: bdxr-help@lists.oasis-open.org -- /chet ---------------- Chet Ensign Director of Standards Development and TC Administration OASIS: Advancing open standards for the information society http://www.oasis-open.org Primary: +1 973-996-2298 Mobile: +1 201-341-1393 Follow OASIS on: LinkedIn:     http://linkd.in/OASISopen Twitter:         http://twitter.com/OASISopen Facebook:   http://facebook.com/oasis.open --------------------------------------------------------------------- To unsubscribe, e-mail: bdxr-unsubscribe@lists.oasis-open.org For additional commands, e-mail: bdxr-help@lists.oasis-open.org -- Robin Cover OASIS, Director of Information Services Editor, Cover Pages and XML Daily Newslink Email: robin@oasis-open.org Staff bio: http://www.oasis-open.org/people/staff/robin-cover Cover Pages: http://xml.coverpages.org/ Newsletter: http://xml.coverpages.org/newsletterArchive.html Tel: +1 972-296-1783


  • 7.  Re: [bdxr] Error in the published charter

    Posted 05-15-2012 16:24
    Good idea Chet, I will update the webpage today. /Kenneth On 5/15/12 8:50 AM, "Chet Ensign" <chet.ensign@oasis-open.org> wrote: >Kenneth, Andrea - > >Can I suggest that you can put the Liaisons material on the TC's main >web page? That would make it even more evident than on the charter >page. > >/chet > >On Tue, May 15, 2012 at 1:27 AM, Kenneth Bengtsson <kenneth@alfa1lab.com> >wrote: >> Dear Andrea >> >> Per request from OASIS the "Liaisons" section was moved to the >>non-normative >> part of the TC rechartering proposal. Please see attached. >> >> Best regards, >> >> Kenneth >> >> >> From: Andrea Caccia <andrea.caccia@studiocaccia.com> >> Date: Monday, May 14, 2012 6:21 PM >> To: <bdxr@lists.oasis-open.org> >> Subject: [bdxr] Error in the published charter >> >> Dear TC, >> I noticed that in the published TC charter the last section "Liaisons" >>is >> missing, this has to be fixed. >> This can be easily verified comparing the currently published charter >> here: http://www.oasis-open.org/committees/bdxr/charter.php with the >> rechartering proposal that has been formally voted and approved, >>published >> here: http://wiki.oasis-open.org/bdx/Recharter >> >> Best regards >> Andrea Caccia >> >> >> ---------- Forwarded message ---------- >> From: Chet Ensign <chet.ensign@oasis-open.org> >> To: Kenneth Bengtsson <kenneth@alfa1lab.com>, bdx@lists.oasis-open.org >> Cc: >> Date: Thu, 12 Apr 2012 11:30:33 -0400 >> Subject: [bdx] Revisions to the submitted revised charter >> Hi Kenneth, >> >> Here are the revisions I would like you to make to the submission. >> >> So that I have everything in one communication, would you put a note >> at the beginning stating that the TC approved requesting a Special >> Majority Ballot to approve its revised charter in its meeting of >> <date> and provide a link to those minutes. I know that you gave me >> that elsewhere, it will just make life simpler if I have everything in >> one place. >> >> Please move the paragraph labelled "Liaisons:" to the non-normative >> section of the submission. Please put that in the "Similar or >> applicable work:" section. You can add it as a second paragraph. >> >> Regarding the First meeting - I believe GoToMeeting always provides a >> call in number for those that can't access the over the Internet. >> While this will sound a bit crazy in this day and age, there are >> companies (such as Bloomberg LP, the last place I worked) that don't >> allow employees to use web meeting software or even Skype! So please >> add a sentence saying something like "A conference calling number will >> be available for any participants who cannot access the meeting >> online" to make sure the meeting is inclusive. >> >> On the list of members supporting rechartering, as you are an >> individual member, your affiliation needs to be "Individual member" >> not Alfa1lab. >> >> You will need an org statement of support from Difi-Agency or, >> alternately, remove Klaus from the list. >> >> You need to add "Name of the Convener:" as the last section. I am >> assuming that you are acting as convener so you can just copy your >> information there. >> >> That's it. I'll start setting up the ballot now so it can get launched >> right away. >> >> -- >> >> /chet >> ---------------- >> Chet Ensign >> Director of Standards Development and TC Administration >> OASIS: Advancing open standards for the information society >> http://www.oasis-open.org >> >> Primary: +1 973-996-2298 >> Mobile: +1 201-341-1393 >> >> Follow OASIS on: >> LinkedIn: http://linkd.in/OASISopen >> Twitter: http://twitter.com/OASISopen >> Facebook: http://facebook.com/oasis.open >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: bdx-unsubscribe@lists.oasis-open.org >> For additional commands, e-mail: bdx-help@lists.oasis-open.org >> >> >> >> ---------- Forwarded message ---------- >> From: Kenneth Bengtsson <kenneth@alfa1lab.com> >> To: Chet Ensign <chet.ensign@oasis-open.org> >> Cc: "bdx@lists.oasis-open.org" <bdx@lists.oasis-open.org> >> Date: Thu, 12 Apr 2012 10:59:49 -0500 >> Subject: [bdx] OASIS Business Document Exchange (BDX) Technical >>Committee >> rechartering >> Dear TC Admin >> >> To move the work of the OASIS Business Document Exchange (BDX) Technical >> Committee into a broader scope and to accommodate requirements raised by >> BDX adopters, the TC has decided to formally propose the new Charter >> below. The decision to submit the new charter and to commence the formal >> rechartering process was taken at the TC's meeting on March 14 2012 and >> recorded in the minutes of that meeting. The minutes are available here: >> >> >> http://www.oasis-open.org/apps/org/workgroup/bdx/document.php?document_id >>=4 >> 5438 >> >> >> >> Name of the TC: >> OASIS Business Document Exchange TC >> >> Statement of Purpose: >> The BDX standard will describe an architecture (or sets of reference >> architectures) where two entities exchange business documents in a >>secure >> and reliable way through the use of gateways (sometimes also referred to >> as access points), which is also known as the "four-corner model". >> >> The purpose of the TC is therefore to define the specifications of a >> lightweight and federated messaging and trust infrastructure for >>reliable >> data exchange, messaging and web services interoperability between >> domains. Here, a "domain" can be any community whose members (a) are >> connected through a shared system, and (b) may interact with others >>across >> domains. >> >> Regardless of each domain's internal workings, such interactions entail >> them each consuming and exposing to others over the Internet certain >> interfaces. These specifications should provide a framework for domains >>to >> interoperate securely and reliably (via Web Services), which can >>therefore >> be viewed as an Inter-cloud Web Services framework. >> >> The TC specifications should be lightweight but, wherever and to the >> extent possible, based on profiles of existing standards from OASIS and >> elsewhere that are widely-used and proven, or otherwise seen to be >> generally applicable. Approaches that are modular and agnostic about >>data >> content and implementation architectures will be preferred. >> >> The TC will focus first on requirements for exchanges between groups of >> related domains around standardized processes/data. Requirements of >> cross-domain business documents exchange, with its corresponding use >> cases, and implied interoperability requirements will inform >> prioritization of the TC's initial deliverables. The TC will >>specifically >> address requirements submitted by the Large Scale Pilots ("LSPs") in the >> area of e-government PEPPOL and e-CODEX. The work of the TC will >> contribute to the ongoing convergence of Pan-European messaging and >>trust >> infrastructures for reliable data exchange. >> >> In certain areas the work will therefore initially be centered on the >>work >> of these LSPs (notably on SMLP around identity and service discovery, >> addressing and profiling), and will also consider other approaches and >> related specifications (e.g. DNS, ebXML CPA, UDDI, ebXML RegRep, >> WS-Discovery), The TC may define or profile more than one such >> specification(s). >> >> In other areas, published specifications today may be absent or have >>gaps. >> In such cases the TC will attempt to identify relevant standards or >> work-in-progress at OASIS or other SDOs to establish liaisons with and >> provide requirements for such efforts, as needed. >> >> Scope of work of the TC: >> The specific objectives will be to define, specify and maintain the >> following: >> >> 1. Use cases and requirements, based on submissions; >> 2. Profiling / gap analysis of existing standards with reference to the >> use cases and requirements, potentially including: >> a) Addressing / Routing / Discovery (SML and related technologies) >> b) Service profiles/Capabilities (SMP, CPA and others) >> c) Identity/Authentication >> d) Trust Frameworks >> e) Transport / Reliable Messaging (e.g. AS4) >> 3. Unified architecture for all processes necessary and sufficient for >>the >> superset of supported use cases; >> 4. Specifications for SML/SMP will be developed within the TC; >> 5. PEPPOL specifications for the START and LIME protocols. >> >> List of deliverables: >> Technical specifications for protocols supporting distributed discovery >>of >> locations and e-business and technical capabilities of exchange >>partners. >> >> Profiles of B2B messaging protocols for use in four-corner (or >> multi-corner) topologies. >> >> IPR Mode under which the TC will operate: >> The TC will operate under the Non-Assertion Mode. >> >> The anticipated audience or users of the work: >> The initial target groups for the TC are: >> >> - Enterprise procurement vendors and supplier networks >> - Software companies (e.g. providers of middleware and business >> applications) >> - Supplier information management providers >> - Public institutions >> - Financial institutions and payment networks >> - Large private companies >> >> Language of the Technical Committee: >> The business of the Technical Committee will be conducted in English. >> >> >> Non-normative information regarding the rechartering of the TC: >> >> Similar or applicable work: >> There are OASIS TC's and other standards bodies covering topics related >>to >> the BDX TC: ebMS, ebXML CPA, UDDI, ebXML RegRep, WS-Discovery, AMQP and >> ETSI REM. The BDX TC is not competing with any of these existing >>standards >> but will build upon their existing specifications to define a complete >> infrastructure architecture. >> >> Liaisons: The initial list of liaisons that will be established >>includes: >> OASIS ebXML Technical Committees, ETSI ESI and OASIS Identity in the >>Cloud >> TC. Other liaisons will be established in the course of the work. >> >> >> First meeting: >> First meeting of the rechartered TC will be held May 2nd 2012 at 16.00 >> CEST. The meeting will be held online. Access to the meeting is provided >> through https://www4.gotomeeting.com/join/925073807 . A conference >>calling >> number will be available for any participants who cannot access the >> meeting online. >> >> >> Meeting schedule: >> The TC will hold weekly conference calls and in addition two >>face-to-face >> meetings a year (November and May). Face-to-face meetings will be >> sponsored by the members of the TC. >> >> Members supporting the rechartering of the TC: >> Kenneth Bengtsson, kenneth@alfa1lab.com, individual member >> Mikkel Hippe Brun, mhb@tradeshift.com, Tradeshift Network Ltd. >> Andrea Caccia, andrea.caccia@studiocaccia.com, AITI-Associazione >>Italiana >> Tesorieri de Impresa >> Pim van der Eijk, pvde@sonnenglanz.net, Sonnenglanz Consulting >> Tim McGrath, tim.mcgrath@documentengineeringservices.com, Document >> Engineering Services Limited >> Sven Rasmussen, svrr@itst.dk, Denmark Ministry of Science, Technology & >> Innovation / DIGST >> Susanne Wigaard, Susanne.Wigard@it.nrw.de, Land Nordrhein-Westfalen >> >> Organizational members' statements of support: >> Document Engineering Services Limited: >> "Having been a supporter of the original Business Document Exchange TC's >> charter, Document Engineering Services fully supports the rechartering >>of >> the BDX TC as proposed." >> >> Sonnenglanz Consulting: >> "Sonnenglanz Consulting supports the proposed rechartering of the BDX >>TC, >> as agreed in the BDX TC meeting of March 14th and recorded in the >>minutes >> >> http://www.oasis-open.org/apps/org/workgroup/bdx/document.php?document_id >>=4 >> 5438 >> >>< http://www.oasis-open.org/apps/org/workgroup/bdx/document.php?document_i >>d= >> 45438.>." >> >> Land Nordrhein-Westfalen: >> "The Land Nordrhein-Westfalen supports the proposed rechartering of the >> BDX TC." >> >> AITI-Associazione Italiana Tesorieri de Impresa: >> "AITI too supports the rechartering." >> >> Denmark Ministry of Science, Technology & Innovation / DIGST: >> "NITA/DIGST also supports the proposed rechartering of the BDX TC, as >> agreed in the BDX TC meeting of March 14th and recorded in the minutes >> >> http://www.oasis-open.org/apps/org/workgroup/bdx/document.php?document_id >>=4 >> 5438 >> >>< http://www.oasis-open.org/apps/org/workgroup/bdx/document.php?document_i >>d= >> 45438.>." >> >> Tradeshift Networks Ltd.: >> "Tradeshift supports the proposed rechartering of the BDX TC, as agreed >>in >> the BDX TC meeting of March 14th and recorded in the minutes >> >> http://www.oasis-open.org/apps/org/workgroup/bdx/document.php?document_id >>=4 >> 5438 >> >>< http://www.oasis-open.org/apps/org/workgroup/bdx/document.php?document_i >>d= >> 45438.>." >> >> Name of the Convener: >> >> The Convener is Kenneth Bengtsson, kenneth@alfa1lab.com >> >> >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: bdx-unsubscribe@lists.oasis-open.org >> For additional commands, e-mail: bdx-help@lists.oasis-open.org >> >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: bdxr-unsubscribe@lists.oasis-open.org >> For additional commands, e-mail: bdxr-help@lists.oasis-open.org > > > >-- > >/chet >---------------- >Chet Ensign >Director of Standards Development and TC Administration >OASIS: Advancing open standards for the information society > http://www.oasis-open.org > >Primary: +1 973-996-2298 >Mobile: +1 201-341-1393 > >Follow OASIS on: >LinkedIn: http://linkd.in/OASISopen >Twitter: http://twitter.com/OASISopen >Facebook: http://facebook.com/oasis.open


  • 8.  Re: [bdxr] Error in the published charter

    Posted 05-15-2012 20:55
    Fine with me too. Andrea Il giorno 15/mag/2012, alle ore 18:23, Kenneth Bengtsson ha scritto: > Good idea Chet, I will update the webpage today. > > /Kenneth > > > On 5/15/12 8:50 AM, "Chet Ensign" <chet.ensign@oasis-open.org> wrote: > >> Kenneth, Andrea - >> >> Can I suggest that you can put the Liaisons material on the TC's main >> web page? That would make it even more evident than on the charter >> page. >> >> /chet >> >> On Tue, May 15, 2012 at 1:27 AM, Kenneth Bengtsson <kenneth@alfa1lab.com> >> wrote: >>> Dear Andrea >>> >>> Per request from OASIS the "Liaisons" section was moved to the >>> non-normative >>> part of the TC rechartering proposal. Please see attached. >>> >>> Best regards, >>> >>> Kenneth >>> >>> >>> From: Andrea Caccia <andrea.caccia@studiocaccia.com> >>> Date: Monday, May 14, 2012 6:21 PM >>> To: <bdxr@lists.oasis-open.org> >>> Subject: [bdxr] Error in the published charter >>> >>> Dear TC, >>> I noticed that in the published TC charter the last section "Liaisons" >>> is >>> missing, this has to be fixed. >>> This can be easily verified comparing the currently published charter >>> here: http://www.oasis-open.org/committees/bdxr/charter.php with the >>> rechartering proposal that has been formally voted and approved, >>> published >>> here: http://wiki.oasis-open.org/bdx/Recharter >>> >>> Best regards >>> Andrea Caccia >>> >>> >>> ---------- Forwarded message ---------- >>> From: Chet Ensign <chet.ensign@oasis-open.org> >>> To: Kenneth Bengtsson <kenneth@alfa1lab.com>, bdx@lists.oasis-open.org >>> Cc: >>> Date: Thu, 12 Apr 2012 11:30:33 -0400 >>> Subject: [bdx] Revisions to the submitted revised charter >>> Hi Kenneth, >>> >>> Here are the revisions I would like you to make to the submission. >>> >>> So that I have everything in one communication, would you put a note >>> at the beginning stating that the TC approved requesting a Special >>> Majority Ballot to approve its revised charter in its meeting of >>> <date> and provide a link to those minutes. I know that you gave me >>> that elsewhere, it will just make life simpler if I have everything in >>> one place. >>> >>> Please move the paragraph labelled "Liaisons:" to the non-normative >>> section of the submission. Please put that in the "Similar or >>> applicable work:" section. You can add it as a second paragraph. >>> >>> Regarding the First meeting - I believe GoToMeeting always provides a >>> call in number for those that can't access the over the Internet. >>> While this will sound a bit crazy in this day and age, there are >>> companies (such as Bloomberg LP, the last place I worked) that don't >>> allow employees to use web meeting software or even Skype! So please >>> add a sentence saying something like "A conference calling number will >>> be available for any participants who cannot access the meeting >>> online" to make sure the meeting is inclusive. >>> >>> On the list of members supporting rechartering, as you are an >>> individual member, your affiliation needs to be "Individual member" >>> not Alfa1lab. >>> >>> You will need an org statement of support from Difi-Agency or, >>> alternately, remove Klaus from the list. >>> >>> You need to add "Name of the Convener:" as the last section. I am >>> assuming that you are acting as convener so you can just copy your >>> information there. >>> >>> That's it. I'll start setting up the ballot now so it can get launched >>> right away. >>> >>> -- >>> >>> /chet >>> ---------------- >>> Chet Ensign >>> Director of Standards Development and TC Administration >>> OASIS: Advancing open standards for the information society >>> http://www.oasis-open.org >>> >>> Primary: +1 973-996-2298 >>> Mobile: +1 201-341-1393 >>> >>> Follow OASIS on: >>> LinkedIn: http://linkd.in/OASISopen >>> Twitter: http://twitter.com/OASISopen >>> Facebook: http://facebook.com/oasis.open >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: bdx-unsubscribe@lists.oasis-open.org >>> For additional commands, e-mail: bdx-help@lists.oasis-open.org >>> >>> >>> >>> ---------- Forwarded message ---------- >>> From: Kenneth Bengtsson <kenneth@alfa1lab.com> >>> To: Chet Ensign <chet.ensign@oasis-open.org> >>> Cc: "bdx@lists.oasis-open.org" <bdx@lists.oasis-open.org> >>> Date: Thu, 12 Apr 2012 10:59:49 -0500 >>> Subject: [bdx] OASIS Business Document Exchange (BDX) Technical >>> Committee >>> rechartering >>> Dear TC Admin >>> >>> To move the work of the OASIS Business Document Exchange (BDX) Technical >>> Committee into a broader scope and to accommodate requirements raised by >>> BDX adopters, the TC has decided to formally propose the new Charter >>> below. The decision to submit the new charter and to commence the formal >>> rechartering process was taken at the TC's meeting on March 14 2012 and >>> recorded in the minutes of that meeting. The minutes are available here: >>> >>> >>> http://www.oasis-open.org/apps/org/workgroup/bdx/document.php?document_id >>> =4 >>> 5438 >>> >>> >>> >>> Name of the TC: >>> OASIS Business Document Exchange TC >>> >>> Statement of Purpose: >>> The BDX standard will describe an architecture (or sets of reference >>> architectures) where two entities exchange business documents in a >>> secure >>> and reliable way through the use of gateways (sometimes also referred to >>> as access points), which is also known as the "four-corner model". >>> >>> The purpose of the TC is therefore to define the specifications of a >>> lightweight and federated messaging and trust infrastructure for >>> reliable >>> data exchange, messaging and web services interoperability between >>> domains. Here, a "domain" can be any community whose members (a) are >>> connected through a shared system, and (b) may interact with others >>> across >>> domains. >>> >>> Regardless of each domain's internal workings, such interactions entail >>> them each consuming and exposing to others over the Internet certain >>> interfaces. These specifications should provide a framework for domains >>> to >>> interoperate securely and reliably (via Web Services), which can >>> therefore >>> be viewed as an Inter-cloud Web Services framework. >>> >>> The TC specifications should be lightweight but, wherever and to the >>> extent possible, based on profiles of existing standards from OASIS and >>> elsewhere that are widely-used and proven, or otherwise seen to be >>> generally applicable. Approaches that are modular and agnostic about >>> data >>> content and implementation architectures will be preferred. >>> >>> The TC will focus first on requirements for exchanges between groups of >>> related domains around standardized processes/data. Requirements of >>> cross-domain business documents exchange, with its corresponding use >>> cases, and implied interoperability requirements will inform >>> prioritization of the TC's initial deliverables. The TC will >>> specifically >>> address requirements submitted by the Large Scale Pilots ("LSPs") in the >>> area of e-government PEPPOL and e-CODEX. The work of the TC will >>> contribute to the ongoing convergence of Pan-European messaging and >>> trust >>> infrastructures for reliable data exchange. >>> >>> In certain areas the work will therefore initially be centered on the >>> work >>> of these LSPs (notably on SMLP around identity and service discovery, >>> addressing and profiling), and will also consider other approaches and >>> related specifications (e.g. DNS, ebXML CPA, UDDI, ebXML RegRep, >>> WS-Discovery), The TC may define or profile more than one such >>> specification(s). >>> >>> In other areas, published specifications today may be absent or have >>> gaps. >>> In such cases the TC will attempt to identify relevant standards or >>> work-in-progress at OASIS or other SDOs to establish liaisons with and >>> provide requirements for such efforts, as needed. >>> >>> Scope of work of the TC: >>> The specific objectives will be to define, specify and maintain the >>> following: >>> >>> 1. Use cases and requirements, based on submissions; >>> 2. Profiling / gap analysis of existing standards with reference to the >>> use cases and requirements, potentially including: >>> a) Addressing / Routing / Discovery (SML and related technologies) >>> b) Service profiles/Capabilities (SMP, CPA and others) >>> c) Identity/Authentication >>> d) Trust Frameworks >>> e) Transport / Reliable Messaging (e.g. AS4) >>> 3. Unified architecture for all processes necessary and sufficient for >>> the >>> superset of supported use cases; >>> 4. Specifications for SML/SMP will be developed within the TC; >>> 5. PEPPOL specifications for the START and LIME protocols. >>> >>> List of deliverables: >>> Technical specifications for protocols supporting distributed discovery >>> of >>> locations and e-business and technical capabilities of exchange >>> partners. >>> >>> Profiles of B2B messaging protocols for use in four-corner (or >>> multi-corner) topologies. >>> >>> IPR Mode under which the TC will operate: >>> The TC will operate under the Non-Assertion Mode. >>> >>> The anticipated audience or users of the work: >>> The initial target groups for the TC are: >>> >>> - Enterprise procurement vendors and supplier networks >>> - Software companies (e.g. providers of middleware and business >>> applications) >>> - Supplier information management providers >>> - Public institutions >>> - Financial institutions and payment networks >>> - Large private companies >>> >>> Language of the Technical Committee: >>> The business of the Technical Committee will be conducted in English. >>> >>> >>> Non-normative information regarding the rechartering of the TC: >>> >>> Similar or applicable work: >>> There are OASIS TC's and other standards bodies covering topics related >>> to >>> the BDX TC: ebMS, ebXML CPA, UDDI, ebXML RegRep, WS-Discovery, AMQP and >>> ETSI REM. The BDX TC is not competing with any of these existing >>> standards >>> but will build upon their existing specifications to define a complete >>> infrastructure architecture. >>> >>> Liaisons: The initial list of liaisons that will be established >>> includes: >>> OASIS ebXML Technical Committees, ETSI ESI and OASIS Identity in the >>> Cloud >>> TC. Other liaisons will be established in the course of the work. >>> >>> >>> First meeting: >>> First meeting of the rechartered TC will be held May 2nd 2012 at 16.00 >>> CEST. The meeting will be held online. Access to the meeting is provided >>> through https://www4.gotomeeting.com/join/925073807 . A conference >>> calling >>> number will be available for any participants who cannot access the >>> meeting online. >>> >>> >>> Meeting schedule: >>> The TC will hold weekly conference calls and in addition two >>> face-to-face >>> meetings a year (November and May). Face-to-face meetings will be >>> sponsored by the members of the TC. >>> >>> Members supporting the rechartering of the TC: >>> Kenneth Bengtsson, kenneth@alfa1lab.com, individual member >>> Mikkel Hippe Brun, mhb@tradeshift.com, Tradeshift Network Ltd. >>> Andrea Caccia, andrea.caccia@studiocaccia.com, AITI-Associazione >>> Italiana >>> Tesorieri de Impresa >>> Pim van der Eijk, pvde@sonnenglanz.net, Sonnenglanz Consulting >>> Tim McGrath, tim.mcgrath@documentengineeringservices.com, Document >>> Engineering Services Limited >>> Sven Rasmussen, svrr@itst.dk, Denmark Ministry of Science, Technology & >>> Innovation / DIGST >>> Susanne Wigaard, Susanne.Wigard@it.nrw.de, Land Nordrhein-Westfalen >>> >>> Organizational members' statements of support: >>> Document Engineering Services Limited: >>> "Having been a supporter of the original Business Document Exchange TC's >>> charter, Document Engineering Services fully supports the rechartering >>> of >>> the BDX TC as proposed." >>> >>> Sonnenglanz Consulting: >>> "Sonnenglanz Consulting supports the proposed rechartering of the BDX >>> TC, >>> as agreed in the BDX TC meeting of March 14th and recorded in the >>> minutes >>> >>> http://www.oasis-open.org/apps/org/workgroup/bdx/document.php?document_id >>> =4 >>> 5438 >>> >>> < http://www.oasis-open.org/apps/org/workgroup/bdx/document.php?document_i >>> d= >>> 45438.>." >>> >>> Land Nordrhein-Westfalen: >>> "The Land Nordrhein-Westfalen supports the proposed rechartering of the >>> BDX TC." >>> >>> AITI-Associazione Italiana Tesorieri de Impresa: >>> "AITI too supports the rechartering." >>> >>> Denmark Ministry of Science, Technology & Innovation / DIGST: >>> "NITA/DIGST also supports the proposed rechartering of the BDX TC, as >>> agreed in the BDX TC meeting of March 14th and recorded in the minutes >>> >>> http://www.oasis-open.org/apps/org/workgroup/bdx/document.php?document_id >>> =4 >>> 5438 >>> >>> < http://www.oasis-open.org/apps/org/workgroup/bdx/document.php?document_i >>> d= >>> 45438.>." >>> >>> Tradeshift Networks Ltd.: >>> "Tradeshift supports the proposed rechartering of the BDX TC, as agreed >>> in >>> the BDX TC meeting of March 14th and recorded in the minutes >>> >>> http://www.oasis-open.org/apps/org/workgroup/bdx/document.php?document_id >>> =4 >>> 5438 >>> >>> < http://www.oasis-open.org/apps/org/workgroup/bdx/document.php?document_i >>> d= >>> 45438.>." >>> >>> Name of the Convener: >>> >>> The Convener is Kenneth Bengtsson, kenneth@alfa1lab.com >>> >>> >>> >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: bdx-unsubscribe@lists.oasis-open.org >>> For additional commands, e-mail: bdx-help@lists.oasis-open.org >>> >>> >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: bdxr-unsubscribe@lists.oasis-open.org >>> For additional commands, e-mail: bdxr-help@lists.oasis-open.org >> >> >> >> -- >> >> /chet >> ---------------- >> Chet Ensign >> Director of Standards Development and TC Administration >> OASIS: Advancing open standards for the information society >> http://www.oasis-open.org >> >> Primary: +1 973-996-2298 >> Mobile: +1 201-341-1393 >> >> Follow OASIS on: >> LinkedIn: http://linkd.in/OASISopen >> Twitter: http://twitter.com/OASISopen >> Facebook: http://facebook.com/oasis.open > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: bdxr-unsubscribe@lists.oasis-open.org > For additional commands, e-mail: bdxr-help@lists.oasis-open.org >


  • 9.  Re: [bdxr] Error in the published charter

    Posted 05-15-2012 20:59
    Thank you Andrea for bringing this up. I have updated the webpage. Best regards, Kenneth On 5/15/12 3:54 PM, "Andrea Caccia" <andrea.caccia@studiocaccia.com> wrote: >Fine with me too. > >Andrea > > >Il giorno 15/mag/2012, alle ore 18:23, Kenneth Bengtsson ha scritto: > >> Good idea Chet, I will update the webpage today. >> >> /Kenneth >> >> >> On 5/15/12 8:50 AM, "Chet Ensign" <chet.ensign@oasis-open.org> wrote: >> >>> Kenneth, Andrea - >>> >>> Can I suggest that you can put the Liaisons material on the TC's main >>> web page? That would make it even more evident than on the charter >>> page. >>> >>> /chet >>> >>> On Tue, May 15, 2012 at 1:27 AM, Kenneth Bengtsson >>><kenneth@alfa1lab.com> >>> wrote: >>>> Dear Andrea >>>> >>>> Per request from OASIS the "Liaisons" section was moved to the >>>> non-normative >>>> part of the TC rechartering proposal. Please see attached. >>>> >>>> Best regards, >>>> >>>> Kenneth >>>> >>>> >>>> From: Andrea Caccia <andrea.caccia@studiocaccia.com> >>>> Date: Monday, May 14, 2012 6:21 PM >>>> To: <bdxr@lists.oasis-open.org> >>>> Subject: [bdxr] Error in the published charter >>>> >>>> Dear TC, >>>> I noticed that in the published TC charter the last section "Liaisons" >>>> is >>>> missing, this has to be fixed. >>>> This can be easily verified comparing the currently published charter >>>> here: http://www.oasis-open.org/committees/bdxr/charter.php with the >>>> rechartering proposal that has been formally voted and approved, >>>> published >>>> here: http://wiki.oasis-open.org/bdx/Recharter >>>> >>>> Best regards >>>> Andrea Caccia >>>> >>>> >>>> ---------- Forwarded message ---------- >>>> From: Chet Ensign <chet.ensign@oasis-open.org> >>>> To: Kenneth Bengtsson <kenneth@alfa1lab.com>, bdx@lists.oasis-open.org >>>> Cc: >>>> Date: Thu, 12 Apr 2012 11:30:33 -0400 >>>> Subject: [bdx] Revisions to the submitted revised charter >>>> Hi Kenneth, >>>> >>>> Here are the revisions I would like you to make to the submission. >>>> >>>> So that I have everything in one communication, would you put a note >>>> at the beginning stating that the TC approved requesting a Special >>>> Majority Ballot to approve its revised charter in its meeting of >>>> <date> and provide a link to those minutes. I know that you gave me >>>> that elsewhere, it will just make life simpler if I have everything in >>>> one place. >>>> >>>> Please move the paragraph labelled "Liaisons:" to the non-normative >>>> section of the submission. Please put that in the "Similar or >>>> applicable work:" section. You can add it as a second paragraph. >>>> >>>> Regarding the First meeting - I believe GoToMeeting always provides a >>>> call in number for those that can't access the over the Internet. >>>> While this will sound a bit crazy in this day and age, there are >>>> companies (such as Bloomberg LP, the last place I worked) that don't >>>> allow employees to use web meeting software or even Skype! So please >>>> add a sentence saying something like "A conference calling number will >>>> be available for any participants who cannot access the meeting >>>> online" to make sure the meeting is inclusive. >>>> >>>> On the list of members supporting rechartering, as you are an >>>> individual member, your affiliation needs to be "Individual member" >>>> not Alfa1lab. >>>> >>>> You will need an org statement of support from Difi-Agency or, >>>> alternately, remove Klaus from the list. >>>> >>>> You need to add "Name of the Convener:" as the last section. I am >>>> assuming that you are acting as convener so you can just copy your >>>> information there. >>>> >>>> That's it. I'll start setting up the ballot now so it can get launched >>>> right away. >>>> >>>> -- >>>> >>>> /chet >>>> ---------------- >>>> Chet Ensign >>>> Director of Standards Development and TC Administration >>>> OASIS: Advancing open standards for the information society >>>> http://www.oasis-open.org >>>> >>>> Primary: +1 973-996-2298 >>>> Mobile: +1 201-341-1393 >>>> >>>> Follow OASIS on: >>>> LinkedIn: http://linkd.in/OASISopen >>>> Twitter: http://twitter.com/OASISopen >>>> Facebook: http://facebook.com/oasis.open >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: bdx-unsubscribe@lists.oasis-open.org >>>> For additional commands, e-mail: bdx-help@lists.oasis-open.org >>>> >>>> >>>> >>>> ---------- Forwarded message ---------- >>>> From: Kenneth Bengtsson <kenneth@alfa1lab.com> >>>> To: Chet Ensign <chet.ensign@oasis-open.org> >>>> Cc: "bdx@lists.oasis-open.org" <bdx@lists.oasis-open.org> >>>> Date: Thu, 12 Apr 2012 10:59:49 -0500 >>>> Subject: [bdx] OASIS Business Document Exchange (BDX) Technical >>>> Committee >>>> rechartering >>>> Dear TC Admin >>>> >>>> To move the work of the OASIS Business Document Exchange (BDX) >>>>Technical >>>> Committee into a broader scope and to accommodate requirements raised >>>>by >>>> BDX adopters, the TC has decided to formally propose the new Charter >>>> below. The decision to submit the new charter and to commence the >>>>formal >>>> rechartering process was taken at the TC's meeting on March 14 2012 >>>>and >>>> recorded in the minutes of that meeting. The minutes are available >>>>here: >>>> >>>> >>>> >>>> http://www.oasis-open.org/apps/org/workgroup/bdx/document.php?document_ >>>>id >>>> =4 >>>> 5438 >>>> >>>> >>>> >>>> Name of the TC: >>>> OASIS Business Document Exchange TC >>>> >>>> Statement of Purpose: >>>> The BDX standard will describe an architecture (or sets of reference >>>> architectures) where two entities exchange business documents in a >>>> secure >>>> and reliable way through the use of gateways (sometimes also referred >>>>to >>>> as access points), which is also known as the "four-corner model". >>>> >>>> The purpose of the TC is therefore to define the specifications of a >>>> lightweight and federated messaging and trust infrastructure for >>>> reliable >>>> data exchange, messaging and web services interoperability between >>>> domains. Here, a "domain" can be any community whose members (a) are >>>> connected through a shared system, and (b) may interact with others >>>> across >>>> domains. >>>> >>>> Regardless of each domain's internal workings, such interactions >>>>entail >>>> them each consuming and exposing to others over the Internet certain >>>> interfaces. These specifications should provide a framework for >>>>domains >>>> to >>>> interoperate securely and reliably (via Web Services), which can >>>> therefore >>>> be viewed as an Inter-cloud Web Services framework. >>>> >>>> The TC specifications should be lightweight but, wherever and to the >>>> extent possible, based on profiles of existing standards from OASIS >>>>and >>>> elsewhere that are widely-used and proven, or otherwise seen to be >>>> generally applicable. Approaches that are modular and agnostic about >>>> data >>>> content and implementation architectures will be preferred. >>>> >>>> The TC will focus first on requirements for exchanges between groups >>>>of >>>> related domains around standardized processes/data. Requirements of >>>> cross-domain business documents exchange, with its corresponding use >>>> cases, and implied interoperability requirements will inform >>>> prioritization of the TC's initial deliverables. The TC will >>>> specifically >>>> address requirements submitted by the Large Scale Pilots ("LSPs") in >>>>the >>>> area of e-government PEPPOL and e-CODEX. The work of the TC will >>>> contribute to the ongoing convergence of Pan-European messaging and >>>> trust >>>> infrastructures for reliable data exchange. >>>> >>>> In certain areas the work will therefore initially be centered on the >>>> work >>>> of these LSPs (notably on SMLP around identity and service discovery, >>>> addressing and profiling), and will also consider other approaches and >>>> related specifications (e.g. DNS, ebXML CPA, UDDI, ebXML RegRep, >>>> WS-Discovery), The TC may define or profile more than one such >>>> specification(s). >>>> >>>> In other areas, published specifications today may be absent or have >>>> gaps. >>>> In such cases the TC will attempt to identify relevant standards or >>>> work-in-progress at OASIS or other SDOs to establish liaisons with and >>>> provide requirements for such efforts, as needed. >>>> >>>> Scope of work of the TC: >>>> The specific objectives will be to define, specify and maintain the >>>> following: >>>> >>>> 1. Use cases and requirements, based on submissions; >>>> 2. Profiling / gap analysis of existing standards with reference to >>>>the >>>> use cases and requirements, potentially including: >>>> a) Addressing / Routing / Discovery (SML and related technologies) >>>> b) Service profiles/Capabilities (SMP, CPA and others) >>>> c) Identity/Authentication >>>> d) Trust Frameworks >>>> e) Transport / Reliable Messaging (e.g. AS4) >>>> 3. Unified architecture for all processes necessary and sufficient for >>>> the >>>> superset of supported use cases; >>>> 4. Specifications for SML/SMP will be developed within the TC; >>>> 5. PEPPOL specifications for the START and LIME protocols. >>>> >>>> List of deliverables: >>>> Technical specifications for protocols supporting distributed >>>>discovery >>>> of >>>> locations and e-business and technical capabilities of exchange >>>> partners. >>>> >>>> Profiles of B2B messaging protocols for use in four-corner (or >>>> multi-corner) topologies. >>>> >>>> IPR Mode under which the TC will operate: >>>> The TC will operate under the Non-Assertion Mode. >>>> >>>> The anticipated audience or users of the work: >>>> The initial target groups for the TC are: >>>> >>>> - Enterprise procurement vendors and supplier networks >>>> - Software companies (e.g. providers of middleware and business >>>> applications) >>>> - Supplier information management providers >>>> - Public institutions >>>> - Financial institutions and payment networks >>>> - Large private companies >>>> >>>> Language of the Technical Committee: >>>> The business of the Technical Committee will be conducted in English. >>>> >>>> >>>> Non-normative information regarding the rechartering of the TC: >>>> >>>> Similar or applicable work: >>>> There are OASIS TC's and other standards bodies covering topics >>>>related >>>> to >>>> the BDX TC: ebMS, ebXML CPA, UDDI, ebXML RegRep, WS-Discovery, AMQP >>>>and >>>> ETSI REM. The BDX TC is not competing with any of these existing >>>> standards >>>> but will build upon their existing specifications to define a complete >>>> infrastructure architecture. >>>> >>>> Liaisons: The initial list of liaisons that will be established >>>> includes: >>>> OASIS ebXML Technical Committees, ETSI ESI and OASIS Identity in the >>>> Cloud >>>> TC. Other liaisons will be established in the course of the work. >>>> >>>> >>>> First meeting: >>>> First meeting of the rechartered TC will be held May 2nd 2012 at 16.00 >>>> CEST. The meeting will be held online. Access to the meeting is >>>>provided >>>> through https://www4.gotomeeting.com/join/925073807 . A conference >>>> calling >>>> number will be available for any participants who cannot access the >>>> meeting online. >>>> >>>> >>>> Meeting schedule: >>>> The TC will hold weekly conference calls and in addition two >>>> face-to-face >>>> meetings a year (November and May). Face-to-face meetings will be >>>> sponsored by the members of the TC. >>>> >>>> Members supporting the rechartering of the TC: >>>> Kenneth Bengtsson, kenneth@alfa1lab.com, individual member >>>> Mikkel Hippe Brun, mhb@tradeshift.com, Tradeshift Network Ltd. >>>> Andrea Caccia, andrea.caccia@studiocaccia.com, AITI-Associazione >>>> Italiana >>>> Tesorieri de Impresa >>>> Pim van der Eijk, pvde@sonnenglanz.net, Sonnenglanz Consulting >>>> Tim McGrath, tim.mcgrath@documentengineeringservices.com, Document >>>> Engineering Services Limited >>>> Sven Rasmussen, svrr@itst.dk, Denmark Ministry of Science, Technology >>>>& >>>> Innovation / DIGST >>>> Susanne Wigaard, Susanne.Wigard@it.nrw.de, Land Nordrhein-Westfalen >>>> >>>> Organizational members' statements of support: >>>> Document Engineering Services Limited: >>>> "Having been a supporter of the original Business Document Exchange >>>>TC's >>>> charter, Document Engineering Services fully supports the rechartering >>>> of >>>> the BDX TC as proposed." >>>> >>>> Sonnenglanz Consulting: >>>> "Sonnenglanz Consulting supports the proposed rechartering of the BDX >>>> TC, >>>> as agreed in the BDX TC meeting of March 14th and recorded in the >>>> minutes >>>> >>>> >>>> http://www.oasis-open.org/apps/org/workgroup/bdx/document.php?document_ >>>>id >>>> =4 >>>> 5438 >>>> >>>> >>>>< http://www.oasis-open.org/apps/org/workgroup/bdx/document.php?document >>>>_i >>>> d= >>>> 45438.>." >>>> >>>> Land Nordrhein-Westfalen: >>>> "The Land Nordrhein-Westfalen supports the proposed rechartering of >>>>the >>>> BDX TC." >>>> >>>> AITI-Associazione Italiana Tesorieri de Impresa: >>>> "AITI too supports the rechartering." >>>> >>>> Denmark Ministry of Science, Technology & Innovation / DIGST: >>>> "NITA/DIGST also supports the proposed rechartering of the BDX TC, as >>>> agreed in the BDX TC meeting of March 14th and recorded in the minutes >>>> >>>> >>>> http://www.oasis-open.org/apps/org/workgroup/bdx/document.php?document_ >>>>id >>>> =4 >>>> 5438 >>>> >>>> >>>>< http://www.oasis-open.org/apps/org/workgroup/bdx/document.php?document >>>>_i >>>> d= >>>> 45438.>." >>>> >>>> Tradeshift Networks Ltd.: >>>> "Tradeshift supports the proposed rechartering of the BDX TC, as >>>>agreed >>>> in >>>> the BDX TC meeting of March 14th and recorded in the minutes >>>> >>>> >>>> http://www.oasis-open.org/apps/org/workgroup/bdx/document.php?document_ >>>>id >>>> =4 >>>> 5438 >>>> >>>> >>>>< http://www.oasis-open.org/apps/org/workgroup/bdx/document.php?document >>>>_i >>>> d= >>>> 45438.>." >>>> >>>> Name of the Convener: >>>> >>>> The Convener is Kenneth Bengtsson, kenneth@alfa1lab.com >>>> >>>> >>>> >>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: bdx-unsubscribe@lists.oasis-open.org >>>> For additional commands, e-mail: bdx-help@lists.oasis-open.org >>>> >>>> >>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: bdxr-unsubscribe@lists.oasis-open.org >>>> For additional commands, e-mail: bdxr-help@lists.oasis-open.org >>> >>> >>> >>> -- >>> >>> /chet >>> ---------------- >>> Chet Ensign >>> Director of Standards Development and TC Administration >>> OASIS: Advancing open standards for the information society >>> http://www.oasis-open.org >>> >>> Primary: +1 973-996-2298 >>> Mobile: +1 201-341-1393 >>> >>> Follow OASIS on: >>> LinkedIn: http://linkd.in/OASISopen >>> Twitter: http://twitter.com/OASISopen >>> Facebook: http://facebook.com/oasis.open >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: bdxr-unsubscribe@lists.oasis-open.org >> For additional commands, e-mail: bdxr-help@lists.oasis-open.org >> > > >--------------------------------------------------------------------- >To unsubscribe, e-mail: bdxr-unsubscribe@lists.oasis-open.org >For additional commands, e-mail: bdxr-help@lists.oasis-open.org >


  • 10.  Re: [bdxr] Generalizing metadata service discovery mechanism using DNS capabilities

    Posted 05-15-2012 20:01
    Hi Dale Thanks for the very interesting document, and I'm looking tremendously forward to your presentation tomorrow! Just to few clarify that the SML and the SMP are two different specifications, without any mutual dependencies. In slide 3 you describe the address for service metadata as: http://<hash over recipientID>.<schemeID>.<SML domain>/<recipientID>/services/<documentType> Note that only the hostname part ( <hash over recipientID>.<schemeID>.<SML domain> ) belongs to the SML specification. The path ( /<recipientID>/services/<documentType> ) is part of the REST interface described in the SMP spec. Keeping this distinction between SML and SMP may actually answer some of your questions in slide 4: 2) Can the hostname part convention be altered? We can definitely change the SML hostname convention without changing the SMLP architecture and without concern for SMP. I essentially agree with you that the SML specification is very hardcoded the PEPPOL mindset where there is one central authority governing the users of the architecture. A more flexible/generalized approach, such as you describe, will in my opinion be appropriate. 3) Can there be many different SMP domains? In the PEPPOL architecture there essentially already are many different SMP domains. SMP providers are running their services under their individual domain names. The SML hostname under the  <SML domain>  is just an alias for their respective hostname under their respective domain. I agree with you that using the SML domain alias will cause problems if used with https. 4) Can different communities use different paths? Paths, no. The path is part of the SMP REST scheme. But different communities can use different SML domains. This was part of the original PEPPOL vision, that you can replicate the entire architecture to a different community just by setting up a new SML/DNS service. The current setup does however require that you have some sort of central institution to run the SML service and to decide who can register their services, which may not fit all requirements and use cases. Best regards, Kenneth From: Moberg Dale < dmoberg@axway.com > Date: Monday, May 14, 2012 9:26 AM To: bdxr@lists.oasis-open.org < bdxr@lists.oasis-open.org > Subject: [bdxr] Generalizing metadata service discovery mechanism using DNS capabilities   Please find attached a proposal on a way to discover a URL for a service that could provide connectivity capability ( metadata)   for  internet accessible “X2X “  interactions.   Some of the underlying standards may not be familiar, and if you have time,  here are some background links   http://en.wikipedia.org/wiki/NAPTR_record   An early application in the commercial supply chain (“internet of things”)  (now being updated to the “FONS” standard)   http://www.gs1.org/gsmp/kc/epcglobal/ons/ons_1_0_1-standard-20080529.pdf   Dale Moberg           --------------------------------------------------------------------- To unsubscribe, e-mail: bdxr-unsubscribe@lists.oasis-open.org For additional commands, e-mail: bdxr-help@lists.oasis-open.org


  • 11.  RE: [bdxr] Generalizing metadata service discovery mechanism using DNS capabilities

    Posted 05-15-2012 20:27
    Thanks for your comments, and I understand the distinctions you make (I think!)  I am interested in generalization along all the dimensions of the URI used for a “metadata service”. The metadata service would seem to me to be a possible generalization of SMP concerns, while a NAPTR generalizes some aspects of SML. It seems to me that parts of SML and SMP will be “special cases” of the NAPTR scheme, and it will of course take some time to fully survey what new options can be accomplished, what supplementary tasks of standardization emerge,  and how to fit in other approaches (found in REST, WS and ebXML, for example) into the discovery pattern enabled by the “u” NAPTRs. (I won’t be addressing the “management interface” in SML tomorrow at all, by the way.)  I expect that over time, and with new use cases, there will be a need to consider several ways to “slice and dice” functionality connected with PEPPOL discovery and services.   From: bdxr@lists.oasis-open.org [mailto:bdxr@lists.oasis-open.org] On Behalf Of Kenneth Bengtsson Sent: Tuesday, May 15, 2012 1:01 PM To: Moberg Dale; bdxr@lists.oasis-open.org Subject: Re: [bdxr] Generalizing metadata service discovery mechanism using DNS capabilities   Hi Dale   Thanks for the very interesting document, and I'm looking tremendously forward to your presentation tomorrow!   Just to few clarify that the SML and the SMP are two different specifications, without any mutual dependencies. In slide 3 you describe the address for service metadata as: http://<hash over recipientID>.<schemeID>.<SML domain>/<recipientID>/services/<documentType>   Note that only the hostname part (" <hash over recipientID>.<schemeID>.<SML domain> ") belongs to the SML specification. The path (" /<recipientID>/services/<documentType> ") is part of the REST interface described in the SMP spec.   Keeping this distinction between SML and SMP may actually answer some of your questions in slide 4:   2) Can the hostname part convention be altered? We can definitely change the SML hostname convention without changing the SMLP architecture and without concern for SMP. I essentially agree with you that the SML specification is very hardcoded the PEPPOL mindset where there is one central authority governing the users of the architecture. A more flexible/generalized approach, such as you describe, will in my opinion be appropriate.   3) Can there be many different SMP domains? In the PEPPOL architecture there essentially already are many different SMP domains. SMP providers are running their services under their individual domain names. The SML hostname under the  <SML domain>  is just an alias for their respective hostname under their respective domain. I agree with you that using the SML domain alias will cause problems if used with https.   4) Can different communities use different paths? Paths, no. The path is part of the SMP REST scheme. But different communities can use different SML domains. This was part of the original PEPPOL vision, that you can replicate the entire architecture to a different community just by setting up a new SML/DNS service. The current setup does however require that you have some sort of central institution to run the SML service and to decide who can register their services, which may not fit all requirements and use cases.   Best regards,   Kenneth     From: Moberg Dale < dmoberg@axway.com > Date: Monday, May 14, 2012 9:26 AM To: " bdxr@lists.oasis-open.org " < bdxr@lists.oasis-open.org > Subject: [bdxr] Generalizing metadata service discovery mechanism using DNS capabilities     Please find attached a proposal on a way to discover a URL for a service that could provide connectivity capability ( metadata)   for  internet accessible “X2X “  interactions.   Some of the underlying standards may not be familiar, and if you have time,  here are some background links   http://en.wikipedia.org/wiki/NAPTR_record   An early application in the commercial supply chain (“internet of things”)  (now being updated to the “FONS” standard)   http://www.gs1.org/gsmp/kc/epcglobal/ons/ons_1_0_1-standard-20080529.pdf   Dale Moberg           --------------------------------------------------------------------- To unsubscribe, e-mail: bdxr-unsubscribe@lists.oasis-open.org For additional commands, e-mail: bdxr-help@lists.oasis-open.org


  • 12.  PEPPOL's support for SMEs

    Posted 05-17-2012 00:07
      |   view attached
    Dear Susanne Thank you very much for your interesting presentation today. I actually learned something and now understands e-CODEX somewhat better (I think) :-) I'm attaching the PEPPOL 4-corner drawing that I know you've already seen a million times, but just as a visual aid to help me elaborate on how PEPPOL supports SMEs: The private company in the drawing can be any company who supplies to public sector in Europe. It may be a medium sized or a large company who already does EDI and is well-equipped to implement new standards and procedures, but it may also be a one-man company whose technical capabilities are limited to the use of Gmail. The last example may be a bit extreme, but the point is that PEPPOL cannot assume any capabilities or assign any technical responsibilities to the 1st and 4th corner of the infrastructure. Instead the responsibilities are placed on the shoulders of the 2nd and 3rd corners - the service providers (acting as intermediaries): First of all, service providers required to comply with a set of technical standards and specifications, assuring that every service provider connecting to PEPPOL is able to exchange documents with every other service provider connecting to PEPPOL. Secondly, the service provider is required to sign an agreement with PEPPOL that obligates him to perform certain functions and to provide a certain level of service. This agreement covers (among other things) an obligation to receive messages to his end-users sent through any other service provider in the PEPPOL infrastructure, and to make sure these messages (if compliant with PEPPOL requirements) are delivered all the way to the end-user. The agreement also covers that the service provider must accept messages from his end-users intended for any other end-user of the infrastructure, and that he must deliver these message to the service provider of the recipient in a manner compliant with PEPPOL requirements and specifications. The PEPPOL service provider agreement does not cover how  service providers must interact with their end-users, only that they must  relay message to and from their end-users. In other words, it is only the message exchange between the 2nd and the 3rd corner that is standardized in PEPPOL. The theory here is that where there is a demand there will also be a supply. Where there are companies who want to fully integrate their ERP systems there will also be service providers offering to connect them, and where there are companies who think that Gmail is already a mouthful there will also be service providers who can cater for their needs. Because service providers are obligated to always relay messages between their end-users and other providers in the PEPPOL infrastructure, then every SME (as well as every large organization) has the freedom to choose the service provider that best matches their needs and capabilities, completely independent from what service is used by their trading partner. In a way you can say that for PEPPOL, the technical requirement derived from SME support is that there are no technical requirements for SMEs. Only for their service providers. My take is that this differs a bit from the e-CODEX requirement of avoiding expensive and proprietary infrastructures - at least to my understanding but please put me back in my place if I am wrong. I can also see that a similar structure can support your use case for connecting judicial authorities. Best regards, Kenneth From: < Susanne.Wigard@it.nrw.de > Date: Monday, May 14, 2012 5:11 AM To: < bdxr@lists.oasis-open.org > Cc: < giorgia.lodi@digitpa.gov.it >, < Raia@digitpa.gov.it > Subject: [bdxr] e-CODEX use cases and requirements Dear TC,   Please find attached a first impression of the use cases and requirements from the e-CODEX project ( www.e-codex.eu ). Since the requirements are, at this level, very similar to the ones from PEPPOL, I have referenced Kenneth's presentation and added the e-CODEX viewpoint for better comparability.   Best regards   Susanne     --------------------------------------------------------------------- To unsubscribe, e-mail: bdxr-unsubscribe@lists.oasis-open.org For additional commands, e-mail: bdxr-help@lists.oasis-open.org Attachment: PEPPOL-4-corner.gif Description: GIF image


  • 13.  AW: PEPPOL's support for SMEs

    Posted 05-20-2012 22:28
    Dear Kenneth,   Good to hear the e-CODEX presentation was useful, I felt somewhat  i nsecure about what is interesting to this group and what isn't. What I'd like to do at some later point in time, maybe in a few weeks, is elaborate a bit more on the particulars of our discovery requirements. Also if ever it fits, I would find it interesting to discuss the differences between uses cases that involve some human processing vs. direct EDI application integration.   The 4-corner-drawing I've not only seen but also quoted in our own e-Delivery document ;)   Thank you for your clarification on SME support - if that's basically about not assuming any specific capabilities on the 1st and 4th corner, that would in e-CODEX again map to subsidiarity - existing national systems remain untouched, whatever they may be (and whatever their technical maturity).   However, there seems to be some small difference: where in PEPPOL SMEs can rely on a (commercial) service provider, e-CODEX gateways will be run by governments (ministries of justice), and so they will for their own country define minimum requirements to connect to that gateway. In some countries as far as I know the national Registered Email solutions are in fact commercial, but these service providers don't run their own e-CODEX gateways, but will be connected to the one of their country.   Somewhat confusingly, what we call service providers are the technical systems connected to the gateways, so these sit rather on the 1st and 4th corner. The agreements between the entities running the gateways (that correspond to the PEPPOL agreements) are the basis of what we call the Circle of Trust (the legal details of which are still in the making). Similar to PEPPOL, we also standardize only what's between the 2nd and 3rd corner; how end entities communicate with the gateways is up to the Member States. (We do have defined a backend interface for the default implementation we provide for our partners, however in principle countries can change / replace that backend interface or use an altogether different implementation, as long as it communicates with the other e-CODEX gateways via the standardized (ebMS) protocol.) In fact, we can probably learn a lot from PEPPOL in terms of interoperability agreements.      What corresponds to PEPPOL's service providers, catering for different needs of different user groups, are for e-CODEX the ministries, catering for the needs of their judicial IT infrastructures.   We're not so much concerned about demand and supply - it's governments that decide they have a demand for cross-border e-Justice, and who then decide to run an e-CODEX gateway (and by joining the project as a piloting country, they have already implicitly made that decision).   So in sum you are right that this requirement maps not so much to ours of avoiding proprietary infrastructures, but to the one already mentioned, that (where you have no requirements for SMEs) we have no requirements for the national systems (e.g. case management systems) nor to how they are connected to the e-CODEX gateways (e.g. .some secure national transport infrastructure, or, in the extreme case, gmail). Thank you for pointing this out.   Regarding your last remark, that you see that a similar structure can support your use case for connecting judicial authorities let me just mention that we view the citizens’ communication via the European e-Justice portal just as a special case of this - in fact the e-Justice portal want s to connect to the e-CODEX infrastructure through e-Trustex, very much like e-Trustex is connected to PEPPOL.   Best regards   Susanne     Von: bdxr@lists.oasis-open.org [mailto:bdxr@lists.oasis-open.org] Im Auftrag von Kenneth Bengtsson Gesendet: Donnerstag, 17. Mai 2012 02:07 An: bdxr@lists.oasis-open.org Betreff: [bdxr] PEPPOL's support for SMEs Dear Susanne Thank you very much for your interesting presentation today. I actually learned something and now understands e-CODEX somewhat better (I think) :-) I'm attaching the PEPPOL 4-corner drawing that I know you've already seen a million times, but just as a visual aid to help me elaborate on how PEPPOL supports SMEs: The private company in the drawing can be any company who supplies to public sector in Europe. It may be a medium sized or a large company who already does EDI and is well-equipped to implement new standards and procedures, but it may also be a one-man company whose technical capabilities are limited to the use of Gmail. The last example may be a bit extreme, but the point is that PEPPOL cannot assume any capabilities or assign any technical responsibilities to the 1st and 4th corner of the infrastructure. Instead the responsibilities are placed on the shoulders of the 2nd and 3rd corners - the service providers (acting as intermediaries): First of all, service providers required to comply with a set of technical standards and specifications, assuring that every service provider connecting to PEPPOL is able to exchange documents with every other service provider connecting to PEPPOL. Secondly, the service provider is required to sign an agreement with PEPPOL that obligates him to perform certain functions and to provide a certain level of service. This agreement covers (among other things) an obligation to receive messages to his end-users sent through any other service provider in the PEPPOL infrastructure, and to make sure these messages (if compliant with PEPPOL requirements) are delivered all the way to the end-user. The agreement also covers that the service provider must accept messages from his end-users intended for any other end-user of the infrastructure, and that he must deliver these message to the service provider of the recipient in a manner compliant with PEPPOL requirements and specifications. The PEPPOL service provider agreement does not cover how  service providers must interact with their end-users, only that they must  relay message to and from their end-users. In other words, it is only the message exchange between the 2nd and the 3rd corner that is standardized in PEPPOL. The theory here is that where there is a demand there will also be a supply. Where there are companies who want to fully integrate their ERP systems there will also be service providers offering to connect them, and where there are companies who think that Gmail is already a mouthful there will also be service providers who can cater for their needs. Because service providers are obligated to always relay messages between their end-users and other providers in the PEPPOL infrastructure, then every SME (as well as every large organization) has the freedom to choose the service provider that best matches their needs and capabilities, completely independent from what service is used by their trading partner. In a way you can say that for PEPPOL, the technical requirement derived from SME support is that there are no technical requirements for SMEs. Only for their service providers. My take is that this differs a bit from the e-CODEX requirement of avoiding expensive and proprietary infrastructures - at least to my understanding but please put me back in my place if I am wrong. I can also see that a similar structure can support your use case for connecting judicial authorities. Best regards, Kenneth From: < Susanne.Wigard@it.nrw.de > Date: Monday, May 14, 2012 5:11 AM To: < bdxr@lists.oasis-open.org > Cc: < giorgia.lodi@digitpa.gov.it >, < Raia@digitpa.gov.it > Subject: [bdxr] e-CODEX use cases and requirements Dear TC,   Please find attached a first impression of the use cases and requirements from the e-CODEX project ( www.e-codex.eu ). Since the requirements are, at this level, very similar to the ones from PEPPOL, I have referenced Kenneth's presentation and added the e-CODEX viewpoint for better comparability.   Best regards   Susanne     --------------------------------------------------------------------- To unsubscribe, e-mail: bdxr-unsubscribe@lists.oasis-open.org For additional commands, e-mail: bdxr-help@lists.oasis-open.org