Subject: [P2PSIP] Error Reason Phrase

From: Cullen Jennings <[email-masked]>
Date: Wed, 16 Jul 2008 12:05:17 -0700

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-masked]
https://www.ietf.org/mailman/listinfo/p2psip

---

From: jiangxingfeng 36340 <[email-masked]>
Date: Thu, 17 Jul 2008 09:38:11 +0800

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

---

From: Cullen Jennings <[email-masked]>
Date: Sun, 20 Jul 2008 12:00:44 -0700

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
>
>
>>

---

From: jiangxingfeng 36340 <[email-masked]>
Date: Mon, 21 Jul 2008 15:09:38 +0800

> should return an error. 

Right. How about we list all kinds of possible errors in new version and specify how the intermediate peers do when such kinds of errors are happening? 

>I think this is how the draft is now..

Sorry. When I read through the draft, I don't find descrptions in RELOAD-4  which addressed errors happening on the intermediate peer. All the error codes seems pointing to the errors processed by the responsible peer. Am I missing something? 

Regards!
JiangXingFeng