Subject: [Sipping] I-D ACTION:draft-ietf-sipping-torture-tests-00.txt

From: [email-masked]
Date: Wed, 28 Aug 2002 07:58:12 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Session Initiation Proposal Investigation Working Group of the IETF.

	Title		: Session Initiation Protocol Torture Test Messages
	Author(s)	: A. Johnston et al.
	Filename	: draft-ietf-sipping-torture-tests-00.txt
	Pages		: 30
	Date		: 2002-8-27
	
This informational document gives examples of Session Initiation 
Protocol (SIP) test messages designed to exercise and 'torture' a 
parser.  They were developed as part of the SIPit SIP 
interoperability testing events.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sipping-torture-tests-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-sipping-torture-tests-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-sipping-torture-tests-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 29 Aug 2002 15:19:17 +0300

Hi,

First, I think it's great that the torture tests have been written down in a draft. A general comment is
that I think it would be a good idea to structure the cases depending on, for example, if the server is
supposed to accept the message (ie not  return an error), or if the server is not supposed to accept the
message (return an error). I also think the text for the cases should be a little more consistant.
Sometimes it uses "UAS",  and sometimes "user agent server". Sometimes, when an error shall be sent, the
specific error code is mentioned, and sometime it's not (even if there is a specific code for the
specific case). Anyway, that's cosmetic...

Some comments on some of the test cases:

2.10 Multiple SIP Requests in a Single message
------------------------------------------------

The text says that since the message exceeds the length indicated in the Content-Length header, the
message should be rejected.

I am not sure I agree on this. The Content-Lenght indicates the length of the message-body (if any), not
the SIP message. Also, at the end of the first SIP request there IS a double CRCL, so the receiver should
not care what comes after that.

In other words, I think the receiver SHALL accept the REGISTER request, but discard the INVITE request.

And, even IF the Content-Lenght did indicate the lenght of the INVITE, the INVITE should still be
rejected, since multiple requests aren't allowed.

2.18 INVITE with Garbage after Message Body
-------------------------------------------------

The text says that the server shall reject the request as the body is longer than the Content-Length.

I am not sure I agree on this either. If the part of the message body indicated by the Content-Lenght is
correct from a syntax point of view, the server should not care what comes after that. It simply "cuts"
the message body, using the Content-Length value, from the message, and if the parser accepts it
everything is fine.

2.26 INVITE containing an unknown scheme in the Request URI
------------------------------------------------------------------

The text says that a 400 response shall be sent in this case. I think that a 416 response shall be sent.

All for now...

Regards,

Christer Holmberg
Ericsson Finland

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Alan Johnston <[email-masked]>
Date: Fri, 30 Aug 2002 14:44:44 -0500

Hi Christer,

I'm glad these messages are getting some attention - thanks for your 
comments.  See mine below.

Thanks,
Alan Johnston
sip:[email-masked]

>specific case). Anyway, that's cosmetic...

OK

>2.10 Multiple SIP Requests in a Single message

Unless the message is over TCP in which case Content-Length is the 
separater between messages...

>2.26 INVITE containing an unknown scheme in the Request URI

Right - 416 was a late addition to RFC 3261 to handle sips failures - no 
reason why it won't work here as well.