RE: EDIINT AS2 Status

Marc,

I understand the frustration - dealing with firewalls are always an
annoyance. However, my concern is that is a significant departure from the
general concept of the AS2 protocol. The relative simplicity and openness of
AS2, compared to some other B2B standards, is also what makes it very
attractive to many supply-chains. Given that it is such a mature draft
(widely implemented and hopefully soon to be RFC), making a change of scope
at this point is not wise.

A better approach would be to for a port recommendation within an
organization, like UCC or EAN, than to modify the standard. I believe UCC
has discussed making a AS2 recommendation sheet which would cover profiles
and trading partner arrangements. 

Kyle Meadors
DGI

-----Original Message-----
From: owner-ietf-ediint <at> mail.imc.org [mailto:owner-ietf-ediint <at> mail.imc.org]
On Behalf Of Nurmi, Marc A
Sent: Monday, July 26, 2004 3:45 PM
To: 'Rik Drummond'; ietf-ediint <at> imc.org
Cc: Zeldes, Rick; Redick, Jeffrey A
Subject: RE: EDIINT AS2 Status

If it's not too late, I would like to submit a concern we have about the AS2
standard...

RE: EDIINT AS2 Status

It's only a default port, it doesn't break compatibility.
Regards.
Antoine Alberti

> -----Message d'origine-----
> De : owner-ietf-ediint <at> mail.imc.org
> [mailto:owner-ietf-ediint <at> mail.imc.org]De la part de Kyle Meadors
> Envoyé : mardi 3 août 2004 03:55
> À : 'Nurmi, Marc A'; 'Rik Drummond'; ietf-ediint <at> imc.org
> Cc : 'Zeldes, Rick'; 'Redick, Jeffrey A'
> Objet : RE: EDIINT AS2 Status
> 
> 
> 
> Marc,
> 
> I understand the frustration - dealing with firewalls are always an
> annoyance. However, my concern is that is a significant 
> departure from the
> general concept of the AS2 protocol. The relative simplicity 
> and openness of
> AS2, compared to some other B2B standards, is also what makes it very
> attractive to many supply-chains. Given that it is such a mature draft
> (widely implemented and hopefully soon to be RFC), making a 
> change of scope
> at this point is not wise.
> 
> A better approach would be to for a port recommendation within an
> organization, like UCC or EAN, than to modify the standard. I 

Need Assistance with Interpretation of HTTP Specification

All,

According to section 6.1 of the HTTP 1.1 specification
(ftp://ftp.isi.edu/in-notes/rfc2616.txt) it appears that the HTTP response
message status line MUST include a "reason phrase" following the status
code, the two being separated by a space.  Is that true?  Is that true even
when the reason phrase is empty, as the specification seems to allow?  The
interpretation that seems most appropriate to me is that the reason phrase
is not optional, but may be empty.  That would mean that a response that
does not include a reason phrase (i.e. it is empty) should look as follows:

HTTP/1.1<SP>200<SP><CR><LF>

Any assistance that you can provide regarding an appropriate interpretation
will be greatly appreciated.

Regards,
David Deschenes
EXTOL International

(unknown)

(unknown)