[Dime] RFC3588 7.2 Misleading ABNF

["Tolga Asveren" <asveren at ulticom.com>]

RFC3588 7.2 defines the ABNF to be used for answer messages with a protocol
error return result. It is quite confusing/misleading/not-optimal (or I got
it wrong what it should be).

As the starting assumption, I believe Protocol Errors must be related only
with routing, i.e. erorrs which are interesting from intermediares point of
view. Currently there a few errors classiefed as protocl errors, which
aren't, and hopefully we can have some cleanup there.


I think the idea in 7.2 is:
a)Protocol error answer message must include the original message, e.g. so
that a relay agent can route it to some other peer. I assume *[ AVP ] stands
for that.

b)Protocol error answer message must include Result-Code, so that an
intermediary can decide what to do with that answer. This is why we have {
Result Code }.

So far so good....

c) { Origin-Host } { Origin-Realm }
I assume those are *not* the Origin-Host Origin-Realm AVP of the original
message -7.4 Error-Reporting hints that they aren't-. Why do we need them?
If for troubleshooting, I would opt for Error-Reporting-Host AVP. When a
relay agent receives a protocol error answer, how does it know which
Origin-Host/Origin-Realm AVP to remove -there is also a pair for the
original message, which should be kept intact-.

d) [ Error-Reporting-Host ]
It is a good idea to have an AVP for troubleshooting purposes -as specified
in 7.4-. IMHO, it is better to have this as optional rather than a MUST. I
think, it is a better idea not ise Origin-Host/Origin-Realm for debugging
and rely on this specific AVP.

e) [ Origin-state-Id ] [ Proxy-Info ]
Why are they explicitly mentioned?


Overall, IMO, 7.2 should have said that protocol error answers must include
the original message, Result-Code AVP and may include Error-Reporting-Host
AVP.

    Thanks,
    Tolga




_______________________________________________
DiME mailing list
DiME at ietf.org
https://www1.ietf.org/mailman/listinfo/dime