[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Header names for sender and receiver identifiers...Was RE: EDIINT and HIPAA
This was discussed in our conference call this morning and one of the AS2
Interop participants has already committed their code for release. This
change at this late date would mean a significant hardship for them.
David Fischer
Drummond Group
AS2 Interop Project
david@xxxxxxxxxxxxxxxxx
817.371.8422
-----Original Message-----
From: owner-ietf-ediint@xxxxxxxxxxxx
[mailto:owner-ietf-ediint@xxxxxxxxxxxx]On Behalf Of Moberg, Dale
Sent: Thursday, November 16, 2000 12:12 PM
To: 'chris@xxxxxxxxxxxxxxxxxx'; ietf-ediint@xxxxxxx
Subject: Header names for sender and receiver identiifiers...Was RE:
EDIINT and HIPAA
I would not like to suggest that the identifiers are EDI
specific and therefore would not favor your initial suggestion.
Got others?
On the second issue, before too long changes will be made
in the draft to explain the usage of the headers.
One basic problems stems from the fact that in SMTP and HTTP
the "From" headers have restrictions on values and usages.
In HTTP it points to an admistrative contact of
sorts -- the email address
"on whose behalf" the request has been made.
There are privacy and other caveats not found in an email
context.
In SMTP, "From" is normally the sender's email address,
sometimes used for replies... I here omit a long story.
In both cases it is restricted to be an email
address. (RFCs 822/1123)
For some b2b applications,
different identifier schemes are used to indicate requester
and responder. DUNS numbers might be used or other namespaces
might supply identifiers-- some groups are considering URIs &
URNs for business identifiers, e.g. These identifiers have
"back-end" integration significance and are
independent of the RFC822 email address namespace. Middleware
layers (containing automated user-agents and beyond)
can benefit greatly by customizing configurations,
looked up on the basis of different identity namespaces.
The identity namespaces used for authentication will remain tied
to the trust model's treatment of identity for digital
signatures (for SMIME, certificates; for openPGP, the
various keyrings and extensions to accomodate certificates)
For these reasons, among others, we are introducing new
extension headers to label the values for identifiers in
other namespaces. It has created unnecesary confusion and
potential interoperability obstacles by attempting to
shoehorn different usages into the existing slots. Glad
we found this out now.
Hope that helps.
> -----Original Message-----
> From: chris@xxxxxxxxxxxxxxxxxx [mailto:chris@xxxxxxxxxxxxxxxxxx]
> Sent: Thursday, November 16, 2000 10:20 AM
> To: Moberg, Dale; ietf-ediint@xxxxxxx
> Subject: RE: EDIINT and HIPAA
>
>
> I was afraid you might say that! Actually I'm not clued up
> on why it was
> considered necessary to introduce these headers. The answer
> does not appear
> to be in the AS2 revision in internet-drafts. Perhaps I
> missed it being
> discussed on this list?
>
> How about: "EDI-To" and "EDI-From"
>
> Be happy,
>
> Chris.
>
> ---------- Original Message ----------
> From : "Moberg, Dale" <Dale_Moberg@xxxxxxxxxxxx>
> To : "'chris@xxxxxxxxxxxxxxxxxx'"
> <chris@xxxxxxxxxxxxxxxxxx>,ietf-ediint@xxxxxxx
> Date : Thu, 16 Nov 2000 09:27:22 -0500
> Subject: RE: EDIINT and HIPAA
> >Suggest them now!
> >
> >Dale Moberg
> >
> >
> >> -----Original Message-----
> >> From: chris@xxxxxxxxxxxxxxxxxx [mailto:chris@xxxxxxxxxxxxxxxxxx]
> >> Sent: Thursday, November 16, 2000 5:33 AM
> >> To: ietf-ediint@xxxxxxx
> >> Subject: RE: EDIINT and HIPAA
> >>
> >>
> >> Could we not come up with some more meaningful names for
> >> these new headers?
> >> I'm thinking that in 10 years time no-one will remember what
> >> "AS2-To" means.
> >>
> >> Just a thought.
> >>
> >> Chris.
> >>
> >> >
> >> >I agree, the original AS2 spec was based on AS1, but there
> >> were problems
> >> >discovered during AS2 interoperability testing (using RFC
> >> 822 (email) style
> >> >packaging) related to "To" and "From" headers, which
> resulted in the
> >> >creation
> >> >of two new headers specific to AS2, "AS2-To" and "AS2-From".
> >> We (as the
> >> >authors
> >> >of AS2) will have to provide details of these new routing
> >> headers and
> >> >cannot
> >> >depend entirely on AS1, as we had originally.
> >> >
> >> --
> >> Chris Davenport chris@xxxxxxxxxxxxxxxxxx
> >> Davros Computer Systems
> >>
> --
> Chris Davenport chris@xxxxxxxxxxxxxxxxxx
> Davros Computer Systems
>