[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Comment on RE: HL7 Standards Process (was RE: EDIINT and HIPAA)
- To: "'Dick Brooks'" <dick@xxxxxxxx>, "Rishel,Wes" <wes.rishel@xxxxxxxxxxx>, "'Gunther Schadow'" <gunther@xxxxxxxxxxxxxxxxxxxxxx>
- Subject: Comment on RE: HL7 Standards Process (was RE: EDIINT and HIPAA)
- From: "Moberg, Dale" <Dale_Moberg@xxxxxxxxxxxx>
- Date: Mon, 20 Nov 2000 10:30:01 -0500
- Cc: Rik Drummond <rvd2@xxxxxxxxxxxxxxxx>, Kepa Zubeldia <Kepa.Zubeldia@xxxxxxxxxxx>, CLEM <clem@xxxxxxxxxxxxxxxxxx>, Gary Crough <gcrough@xxxxxxxxxxxxxxxxxxx>, Beth Morrow <Beth@xxxxxxxxxxxxxxxxx>, "David@Drummondgroup. Com" <david@xxxxxxxxxxxxxxxxx>, GISB1@xxxxxxx, ietf-ediint@xxxxxxx
- List-archive: <http://www.imc.org/ietf-ediint/mail-archive/>
- List-id: <ietf-ediint.imc.org>
- List-unsubscribe: <mailto:ietf-ediint-request@imc.org?body=unsubscribe>
- Sender: owner-ietf-ediint@xxxxxxxxxxxx
> -----Original Message-----
> From: Dick Brooks [mailto:dick@xxxxxxxx]
> Sent: Monday, November 20, 2000 9:33 AM
> To: Rishel,Wes; 'Gunther Schadow'
> Cc: Rik Drummond; Kepa Zubeldia; CLEM; Gary Crough; Beth Morrow;
> David@Drummondgroup. Com; GISB1@xxxxxxx; ietf-ediint@xxxxxxx;
> dick@xxxxxxxx
> Subject: RE: HL7 Standards Process (was RE: EDIINT and HIPAA)
> Actually this is an excellent point. The IETF is very
> particular when it
> comes to designing/endorsing standards, as it should be. Some
> of the recent
> concerns with AS1 (see Ned Freed's comments attached) raise the
> probabilities of a longer delay for AS2, because the non-GISB
> portion of AS2
> depends on AS1. I'm not aware of any issues with the GISB
> portion of AS2.
Just a brief comment on a small point raised in passing in the above--
AS 2 references AS 1 and so needs to have AS 1 approved before
moving along. The issues Ned Freed raised concerning the AS 1 option
on compression were SMTP specific really, and that approach is not
referenced
in AS 2, where we mention using the "content-coding" approach of HTTP
(where needed) described in HTTP 2068 section 3.5 (we will update
this before final draft) PGP has its own compression so the content-coding
option would probably not be used if using open-PGP (as in the GISB
profile).
In fact, Ned 's favored approach (use a new content-transfer-encoding for
compression) is like the HTTP procedure. I don't think there is reason
to think there will be any additional delay stemming from the remark
about AS 1 except for the fact that AS 2 references AS 1 and so AS 1 needs
to get through "first".