Tim McGrath | 3 Mar 2000 05:47
Picon

Re: who

is this group still active?

will edi-int be meeting at the adelaide ITEF later this month?

Rik Drummond wrote:

--
regards
tim mcgrath
TEDIS   fremantle  western australia 6160
phone: +618 93352228  fax: +618 93352142

Attachment (tmcgrath.vcf): text/x-vcard, 252 bytes
Rik Drummond | 4 Mar 2000 13:14

status of ebxml work on xml headers

We are currently compiling list of headers from different products and
standards to see which are necessary in the ebxml headers. we will have a
meeting in dallas on april 4-6 to work on these. we intend to author a
strawman on the subject by april 15. ediint is leading these effort inside
of ietf at the moment in cooperation with iotp.

one additional note as2 was submitted to the drafts directory yesterday for
you review. hopefully this is close to finished... best regards, rik

////////////////////////
Rik Drummond           /
CEO Drummond Group     /
v: 817.294.7339        /
f: 817.294.7950         /
www.drummondgroup.com  /
////////////////////////

Rik Drummond | 13 Mar 2000 20:44

FW: FW: please post draft to drafts directory

We have posted the draft to the IETF... but as you can see they will not
post it until after the meeting end of the month. if you wish a copy please
contact dale moberg

-----Original Message-----
From: Internet Draft Submission Manager [mailto:ietfauto <at> ietf.org]
Sent: Monday, March 13, 2000 1:44 PM
To: drummond <at> onramp.net
Subject: Re: FW: please post draft to drafts directory

Greetings,

We are sorry, but the cut-off for Internet-Draft submissions was Friday,
March 10 at 5pm ET. Your submission will not be retained (i.e. you
need to resubmit) after March 7th.

Any submissions received prior to March 26, 2000 will not be retained;
they must be resubmitted. Internet-Draft submissions received on or after
March 27 will be processed. However, Internet-Draft announcements will
not be sent until after the meeting concludes.

If you receive this announcement, your submission will NOT be processed.

Thank you for your understanding.

IETF Secretariat

Rik Drummond | 16 Mar 2000 14:20

ebxml transport working documents

We have a directory of working document that you may access. two of these
are documents on our message header investigation.... best regards, rik

http://www.ebxml.org/working/project_teams/transport

////////////////////////
Rik Drummond           /
CEO Drummond Group     /
v: 817.294.7339        /
f: 817.294.7950         /
www.drummondgroup.com  /
////////////////////////

Rik Drummond | 17 Mar 2000 13:59

ebxml/ietf ediint meeting on ec headers...


below in information on the april ebxml/ediint meeting in dallas on april
4-6. we will be establishing the headers and the envelope for the
transactions.  this joint work effort will solve many of the issues we have
discussed for two years on header extensions in the ediint spec. Is see this
as a joint effort between ebxml/ediint. this meeting is not being held
instead of attending the ietf meeting. i just worked out that it is happing
about the same time and even though there is a good cross section of people
from ediint and ebxml working this issue, we need to get two documents out
asap.

************
The ebXML transport meeting is in Dallas/Fort Worth airport.

Date:				April 4, 5, 6
Times:			10:00am-5:00pm, 8:00am-6:00pm, 8:00am-3:00pm
Hotel: 			Harvey Hotel
Transportation: 		hotel van
Cost of your room at harvey:	about $130
Shared Cost for Conference Room: about $1500
Telephone: 			972.929.4500  USA

The hotel is 1.5 miles from the airport and has van services to the hotel
to/from the airport. When you land, go to baggage claim and call the number
above and request a hotel van.
**************


Just a reminder there is a weekly conference call on thursdays at 11:00 est
until 12:30pm. i will be in japan next week. dick brooks will lead the call
(Continue reading)

Gunther Schadow | 18 Mar 2000 01:14
Picon
Favicon

Re: ebxml/ietf ediint meeting on ec headers...

Rik Drummond wrote:

> below in information on the april ebxml/ediint meeting in dallas on april
> 4-6. we will be establishing the headers and the envelope for the
> transactions.  this joint work effort will solve many of the issues we have
> discussed for two years on header extensions in the ediint spec. Is see this

Yes!!! I have to be on that group, although I can not participate 
in this particular meeting. However ...

> Just a reminder there is a weekly conference call on thursdays at 11:00 est
> until 12:30pm.

What is the number and instructions to dial in?

> our working documents are at
> http://www.ebxml.org/working/project_teams/transport

Will prepare myself for next Thursday.

regards
-Gunther

(of HL7)
Attachment (gunther.vcf): text/x-vcard, 333 bytes
Tim McGrath | 20 Mar 2000 00:01
Picon

Re: ebxml/ietf ediint meeting on ec headers...

it is actually being held the week following the IETF meeting.

is anyone interested in meeting to discuss this at the IETF meeting?

Rik Drummond wrote:

> below in information on the april ebxml/ediint meeting in dallas on april
> 4-6. we will be establishing the headers and the envelope for the
> transactions.  this joint work effort will solve many of the issues we have
> discussed for two years on header extensions in the ediint spec. Is see this
> as a joint effort between ebxml/ediint. this meeting is not being held
> instead of attending the ietf meeting. i just worked out that it is happing
> about the same time and even though there is a good cross section of people
> from ediint and ebxml working this issue, we need to get two documents out
> asap.
>
> ************
> The ebXML transport meeting is in Dallas/Fort Worth airport.
>
> Date:                           April 4, 5, 6
> Times:                  10:00am-5:00pm, 8:00am-6:00pm, 8:00am-3:00pm
> Hotel:                  Harvey Hotel
> Transportation:                 hotel van
> Cost of your room at harvey:    about $130
> Shared Cost for Conference Room: about $1500
> Telephone:                      972.929.4500  USA
>
> The hotel is 1.5 miles from the airport and has van services to the hotel
> to/from the airport. When you land, go to baggage claim and call the number
> above and request a hotel van.
(Continue reading)

J. David MacDonald | 20 Mar 2000 06:02
Picon
Favicon

HTTP Multipart Response, is this reasonable?

Can someone comment on the use of the following structure for EDI-INT usage.
Specifically, is the Multipart/mixed (see below) content-type permissible in
EDI-INT.

SCENARIO.

Client submits a transaction via HTTP.  Neither the EDI response transaction
nor the MDN response is available immediately (the inbound transaction from
the client is queued to a back-end system for processing.)

The back-end system decrypts/verifies the inbound transaction and generates
an MDN for it.  It also forwards the EDI content to an application subsystem
for processing.

The MDN and eventually the EDI response go out to a queue for pickup by the
client.

The client signs on an hour later to retrieve the results.  Rather than do
individual HTTP request/response pairs (one for each transaction sitting in
the queue), is it reasonable to do just a single HTTP request, and have the
server return as the HTTP response all transactions wrapped in a multipart
structure.

EDI-INT-AS2-06 alludes to this but comes up short on a specific example:
"In general, both HTTP servers and HTTP clients handling the message
templates of AS1 should be prepared to process these basic EDIINT data
formats when they are embedded within MIME multiparts".

EXAMPLE OF THE HTTP MULTIPART RESPONSE:
(1st part is the MDN)
(Continue reading)

Carl Hage | 20 Mar 2000 20:46

Re: HTTP Multipart Response, is this reasonable?

From:           	"J. David MacDonald" <david.macdonald <at> sympatico.ca>
Date sent:      	Mon, 20 Mar 2000 00:02:59 -0500

A response message and MDN can be combined, but not under this 
scenario. A client cannot "sign on" later for pickup [except as a POP3
client for SMTP-based delivery]. Transactions are only sent via push 
technology, i.e. either email to the original sender, or an HTTP post to 
the orignal sender's http server. (A sender cannot poll the original 
recipient's http server.)

Normally, the MDN response is generated immediately. (Like a P.O. 
sent by FedEx or certified mail, where a reciept is signed at delivery, 
not when processed.) 

A deferred receipt can be prearranged using the
"Receipt-delivery-option" header, sent by the client.

Normally, a multipart EDI message and MDN is to support real-time 
EDI systems which can generate a response transaction immediately 
(within a few seconds).

> SCENARIO.
> 
> Client submits a transaction via HTTP.  Neither the EDI response
> transaction nor the MDN response is available immediately
...
> The client signs on an hour later to retrieve the results.Rather than 
do individual HTTP request/response pairs (one for each transaction 
sitting in the queue), is it reasonable to do just a single HTTP request, 
and have the server return as the HTTP response all transactions 
(Continue reading)

Gregory W. Vesper | 20 Mar 2000 22:50

RE: HTTP Multipart Response, is this reasonable?

Please bear in mind, customers who are using HTTP for large files, say in
excess of 10MB, will require asynchronous transfer of MDNs as opposed to
MDNs on the same connection.  Async MDNs allow you to support full EDIINT
across any transport.  We currently support EDIINT capability over: SMTP,
FTP, HTTP, HTTPS, MQSeries.

There's no reason MDNs should be hard wired to a specific transport.  I
agree on support for synchronous MDNs for HTTP(S), so long as async is an
option..
Cheers,
-Greg.

> -----Original Message-----
> From: owner-ietf-ediint <at> mail.imc.org
> [mailto:owner-ietf-ediint <at> mail.imc.org]On Behalf Of Carl Hage
> Sent: Monday, March 20, 2000 12:46 PM
> To: J. David MacDonald
> Cc: ietf-ediint <at> imc.org
> Subject: Re: HTTP Multipart Response, is this reasonable?
>
>
> From:           	"J. David MacDonald" <david.macdonald <at> sympatico.ca>
> Date sent:      	Mon, 20 Mar 2000 00:02:59 -0500
>
> A response message and MDN can be combined, but not under this
> scenario. A client cannot "sign on" later for pickup [except as a POP3
> client for SMTP-based delivery]. Transactions are only sent via push
> technology, i.e. either email to the original sender, or an HTTP post to
> the orignal sender's http server. (A sender cannot poll the original
> recipient's http server.)
(Continue reading)


Gmane