Subject: [SIP] More Torture Test Messages Available

From: Neil Deason <[email-masked]>
Date: Tue, 21 Nov 2000 18:30:01 +0000

The proposed new Torture Test messages have been added to the 
main SIP web site:

http://www.cs.columbia.edu/~hgs/sip/bakeoff/testmsg.html

The new ones are test21.txt onwards. They should also appear in 
the new verion of the SIP Message Flows draft shortly.

SIP bakeoff entrants are strongly encouraged to run these tests. 
In particular entrants to advanced scenario testing at bakeoffs 
will be expected to have passed all torture tests. 

Comments, corrections etc welcome.
Neil.
-- 
Ubiquity Software Corporation, UK        http://www.ubiquity.net

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

---

From: Peter Kjellerstedt <[email-masked]>
Date: Wed, 22 Nov 2000 15:32:52 +0100

> -----Original Message-----
> From: Neil Deason [mailto:[email-masked]]
> Sent: 22 November 2000 14:51
> To: Peter Kjellerstedt
> Cc: [email-masked]'
> Subject: Re: [SIP] More Torture Test Messages Available
> 
> Peter Kjellerstedt wrote:
> > 
> > In test30.txt if the Expires value is in absolute format,
> > then a Date header should be supplied too. Otherwise a UA
> > that has no real-time clock will not be able to tell whether
> > this is in the future or past. Actually I think the Expires
> > value should be compared with the Date header if available
> > since the UA on the other end may have an incorrect notion
> > of time...
> 
> But this isn't a MUST so the test message is legal, bear in
> mind these are torture tests not examples of good practice.

No it is not a MUST, but you cannot expect me to respond with
a 408 if you do not provide me with your time (as I have no RTC...)
The description of the test should at least state what will
happen for servers without knowledge of time. You could also have
another identical test, but with a Date header. And you could
actually have a third test with a Date and an Expires header
that both are in the past, but where the Expires header is
in the future compared to the supplied Date header...

> > Also, I am still lacking a test for this kind of To/From header:
> > 
> >         To: sip:[email-masked] ;tag=[email-masked]
> > 
> > and make sure the tag does not end up as a URL parameter...
> 
> Sorry I forgot to add that one but tests 37 and 38 are pretty 
> similar to this although admittedly they are for a registrar 
> not UAS.

True, test 37 tests it. I did not notice it as it was a REGISTER
request, and I do not really handle REGISTER requests :) It would
probably be a good idea to have an INVITE test for this too.

> Cheers,

//Peter

---

From: Igor Slepchin <[email-masked]>
Date: Wed, 22 Nov 2000 14:17:57 -0500

> > Wait, if protocol is defined as, say
> > 
> > protocol-token = "FOO" | "BAR"
> > 
> > it would be CI. This is consistent with the use in RFC 
> 2616, where all
> > tokens are defined as CI (such as character-set, content-coding,
> > transfer-coding, type, subtype, etc.
> 
> Absolutely. I was just being picky about the grammar of Via 
> headers: it <...>

Arrgh, I guess I missed your point that tokens are CI by default. The reason
I missed it is that case-insensitivity of literals is mentioned in Appendix
C whereas that of tokens is described in section 6.5.

Thank you,
Igor Slepchin