transID issues...
"Bob Wyman" <[email protected]> Mon, 29 Jul 2002 19:09:54 -0400
| Newsgroups | gmane.ietf.apex |
|---|---|
| Message-ID | <C1C4A3C0FEE62A45A35BE7890264FF2788F3A9@monsoon.us.ny.firstrain.com> |
This is a multi-part message in MIME format.
------_=_NextPart_001_01C23755.0C9EDE62
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Using Apex Access as an example of what is a general issue:
=20
1) If an Apex Access service receives a message that has no transID
or an invalid transID, how does it form a valid "reply" message to
indicate the error? The problem is that a reply requires a transID that
is identical to the transID of the message being replied to. If the
transID is missing or invalid, how should the service reply?
2) If an Apex Access service receives a message that does not
conform to the Apex Access DTD's or is invalid XML, how does it decide
what transID to use in a reply? The problem is that if the message
doesn't conform, then any attempt to extract a transID from the message
is probably pure guesswork.
=20
The first problem, invalid or missing transIDs, could be solved by
having the relay check messages to ensure that the transIDs are presnet
and proper. However, doing this check in the relay would require a great
deal of parsing and thus could be a real performance hit.=20
The second problem, extracting transIDs from improperly formed
messages, could be somewhat avoided by having the relay do validation of
messages prior to relaying them. But that won't work since the relay has
no idea what the DTDs or schemas for service specific messages are. Even
if it did have access to the necessary metadata, it would be
prohibitively expensive to do this check for every message. In any case,
even if some relays did these checks properly, it would still be
necessary to know how the service should respond to messages that
slipped through relays that didn't do them.
=20
Comments?
=20
bob wyman
=20
------_=_NextPart_001_01C23755.0C9EDE62
Content-Type: text/html;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<TITLE>Message</TITLE>
<META content=3D"MSHTML 6.00.2716.2200" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D310174922-29072002><FONT face=3DArial size=3D2>Using =
Apex Access as=20
an example of what is a general issue:</FONT></SPAN></DIV>
<DIV><SPAN class=3D310174922-29072002><FONT face=3DArial=20
size=3D2></FONT></SPAN> </DIV>
<DIV><SPAN class=3D310174922-29072002><FONT face=3DArial =
size=3D2> =20
1) If an Apex Access service receives a message that has no transID or =
an=20
invalid transID, how does it form a valid "reply" message to indicate =
the error?=20
The problem is that a reply requires a transID that is identical to the =
transID=20
of the message being replied to. If the transID is missing or =
invalid, how=20
should the service reply?</FONT></SPAN></DIV>
<DIV><SPAN class=3D310174922-29072002> <FONT =
face=3DArial=20
size=3D2>2) If an Apex Access service receives a message that does not =
conform to=20
the Apex Access DTD's or is invalid XML, how does it decide =
what=20
transID to use in a reply? The problem is that if the message doesn't =
conform,=20
then any attempt to extract a transID from the message is probably =
pure=20
guesswork.</FONT></SPAN></DIV>
<DIV><SPAN class=3D310174922-29072002><FONT face=3DArial=20
size=3D2></FONT></SPAN> </DIV>
<DIV><SPAN class=3D310174922-29072002> <FONT =
face=3DArial=20
size=3D2>The first problem, invalid or missing transIDs, could be solved =
by having=20
the relay check messages to ensure that the transIDs are presnet and =
proper.=20
However, doing this check in the relay would require a great deal of =
parsing and=20
thus could be a real performance hit. </FONT></SPAN></DIV>
<DIV><SPAN class=3D310174922-29072002><FONT face=3DArial =
size=3D2> =20
The second problem, extracting transIDs from improperly formed messages, =
could=20
be somewhat avoided by having the relay do validation of =
messages=20
prior to relaying them. But that won't work since the relay has no idea =
what the=20
DTDs or schemas for service specific messages are. Even if it did have =
access to=20
the necessary metadata, it would be prohibitively expensive to do this =
check for=20
every message. In any case, even if some relays did these checks =
properly,=20
it would still be necessary to know how the service should respond to =
messages=20
that slipped through relays that didn't do them.</FONT></SPAN></DIV>
<DIV><SPAN class=3D310174922-29072002><FONT face=3DArial=20
size=3D2></FONT></SPAN> </DIV>
<DIV><SPAN class=3D310174922-29072002> <FONT =
face=3DArial=20
size=3D2>Comments?</FONT></SPAN></DIV>
<DIV><SPAN class=3D310174922-29072002><FONT face=3DArial=20
size=3D2></FONT></SPAN> </DIV>
<DIV><SPAN =
class=3D310174922-29072002> =20
<FONT face=3DArial size=3D2>bob wyman</FONT></SPAN></DIV>
<DIV><SPAN class=3D310174922-29072002><FONT face=3DArial=20
size=3D2></FONT></SPAN> </DIV></BODY></HTML>
------_=_NextPart_001_01C23755.0C9EDE62--