Yes, I agree, I think an intermediate node that has or detects an
error will needs to return an error. For example if a node forwarding
detects that a TTL has been exceeded due to some loop condition, it
should return an error. I think this is how the draft is now.
Cullen
On Jul 16, 2008, at 6:38 PM, jiangxingfeng 36340 wrote:
Hi:
As for error, there are two kinds error in the P2PSIP transaction.
One is what happened on the responsible peer, such as no resource,
etc. The other is what happened while intermediate peers processed
the message, such as hop-by-hop error, no reverse connection, etc.
So a open issue in my mind is whether the peer protocol tries to
catch the latter error. IMHO, it may be helpful in debugging the
system.
Regards!
JiangXingFeng
In section 6.2.3.1, the error response have numeric code, an
"reason
phrase" which is a text string that for any given number code
SHOULD
have it value set to a specific string. There is also an extra
error_info string that can contain extra information to help debut
the
problem. From my point of view, I see absolutely zero value in the
extra "reason_phrase" string and am wondering if we can just get
rid
of it. The protocol for historic reasons also mapped the error
codes
onto http error and error classes (i.e. 3xx, 4xx errors etc).
However,
the protocol does not use any of this anywhere and I worry it
causes
more confusion that it solves. We should consider moving the error
codes just to be sequentially allocated numbers.
_______________________________________________
P2PSIP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/p2psip
_______________________________________________
P2PSIP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/p2psip
