Subject: [SIP] Some discussions

From: [email-masked]
Date: Mon, 16 Oct 2000 12:44:23 +0800 (CST)

Dear All:
    I have some questions to discuss.
    For RFC2543Bis02, I have some doubts, for examples. On page 23, Authorization belongs to request header, But on page 36,it is said it can be used in R & r. Is this contradiction? 
    What's more, the same matter happens on  WWW-Authentication, first, on page 23,it belongs to response header, But on page 37,it is said it can be used in R & r. 
   On Page 45 on content-length, it says "If a server receives a UDP request with a Content-Length, but the value is larger than the size of the body sent in the request, the client SHOULD generate a 400 class response." I want to know
which 400 class response can act as this response code, please give me a detailed response code, according to the 4xx response code listed, none can 
act as this situation.Perhelps this code is under the consideration.
   Thanks a lot!
                      Yours: Ford 

----------------------------------------------
�л�������֮��,������Ӯ��
http://points4u.china.com
�μ���������������ǩ����Ʒ������!
http://auction4u.china.com

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 20 Oct 2000 18:58:45 -0700

>     For RFC2543Bis02, I have some doubts, for examples. On page 23, Authorization belongs to request header, But on page 36,it is said it can be used in R & r. Is this contradiction?

Yes, now fixed. Authorization can, rarely, also appear in responses,
with PGP.

>     What's more, the same matter happens on  WWW-Authentication, first, on page 23,it belongs to response header, But on page 37,it is said it can be used in R & r.

Also fixed. Again, this probably escaped attention since few people are
having requests provide challenges.

> act as this situation.Perhelps this code is under the consideration.

The response code is 400 (not just class), a "Bad Request". As usual, it
is advisable to provide verbal details of why the request was bad, so
that the request can see the errors of its ways, improve and sin no
more. But there are too many ways for requests to be bad, so providing a
response code for all of them is probably not warranted.

I also adjusted the section to indicate that *any* discrepancy between
remaining bytes in a datagram and the Content-Length is to be flagged,
pursuant the recent discussion on not having multiple messages in a
datagram.

Thanks for catching these.

> ÖÐ»ªÍø»ýÉÍÖ®ÂÃ,´ó½±ÈÎÄúÓ®£¡
> ²Î¼ÓÍøÉÏÅÄÂô£¬ÃûÈËÇ©ÃûÎïÆ·ÈÎÄãÕù!