Subject: [SIP] Problem with definition of In-Reply-To grammar

From: Gethin Liddell <[email-masked]>
Date: Wed, 17 May 2000 12:49:43 +0100

hi

I have a problem with the In-Reply-To header, 2543 bis section 6.25 p. 48:

"The In-Reply-To request header field enumerates the call-IDs that this call references or returns.
This allows automatic call distribution systems to route return calls to the originator of the first call and allows
callees to filter calls, so that only calls that return calls they have originated will be accepted. This field is not a
substitute for request authentication.

In-Reply-To =  In-Reply-To   :  1# callid"

If i can refer you to Anders email titled:

Re: [SIP] Another grammar query - Call-ID

then callid has been re-defined as 
"Basically, the field should be treated as an opaque,
uninterpreted identifier, e.g. TEXT-UTF8-TRIM in the grammar."

The problem is that if the In-Reply-To header is:
In-Reply-To: [email-masked], [email-masked]

then this will resolve as a single call-id not two separate ones.

would it not be possible to say make call-id a quoted-string???
This may make little sense for the Call-ID header but it solves the problem here.
what would we then compare on though?  could escaped values get in here which would
stop the efficient byte by byte equality checking that TEXT-UTF8-TRIM provided?

cheers

gethin

-- 
Gethin Liddell
Ubiquity Software Corporation

http://www.ubiquity.net
mailto:[email-masked]

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 17 May 2000 17:24:29 -0400

> stop the efficient byte by byte equality checking that TEXT-UTF8-TRIM provided?

This raises a broader issue. I see no reason why call-IDs should need to
be escaped in some uses, i.e., allowing any UTF-8 string seems overkill.
Call-IDs are just random identifiers not human-generated text, so
there's no reason to allow commas, etc. Allowing "strange" characters
just makes it more difficult for log files and anywhere else they might
appear.

Indeed, earlier we had agreed to use 'token' | 'token' @ 'token' or
something like that as the appropriate BNF entity.

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 18 May 2000 01:30:42 -0400

> something like that as the appropriate BNF entity.

I agree completely. There is no reason to make life more complicated
here.

-Jonathan R.

-- 
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (732) 741-4778
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com

---

From: "Adam B. Roach" <[email-masked]>
Date: Fri, 19 May 2000 05:21:49 -0500 (CDT)

>I agree completely. There is no reason to make life more complicated

To keep overaggressive parsers from choking on e.g.
[email-masked]@domain.com, I'd propose:

token *( "@" token )

...with a RECOMMENDATION that they be of the format currently described
in 2543.

-- 
Adam Roach, Ericsson Inc. |  Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04
[email-masked]   | Fax: +1 972 669 0154 | Richardson, TX 75081 USA

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 19 May 2000 13:45:17 -0400

> ...with a RECOMMENDATION that they be of the format currently described

This wouldn't be backward-compatible. Why encourage such 'strange'
formats?