Subject: Re: Line Folding + Grammar strictiness {RESEND}

From: [email-masked]
Date: Thu, 25 Nov 1999 09:04:14 +0530

Hi,
I we really want userid@host - and currently dont have any other better
alternative,
then probably we should omit the statement in the Notes and Clarifications
doc stating that Call-Id=token should
be allowed.

Also, Im a little confused as to why we should be forgiving for Input - the
problem is that then people do not
take the specified syntax correctly, and we will still have
implementations, being a little more forgiving than others in
various different cases leading to more and more interop problems.

Dont you think that its better, rather, to define the grammar properly
(make the grammar rules more forgiving rather than
allowing variations beyond a defined grammar) ?

For example, the line folding example I mentioned, I saw certain stack
builders provide examples of SIP message with
tabs in front of messages (not folds !) - guess this could be a form of
lenient input, but  I really feel such things should
be discouraged at the spec level and enforced too - that way - every one
has a standard reference at least for the core
message  protocol and at interops we have more complex issues to worry
about !

Regds
Arjun

--
Arjun Roychowdhury @ Hughes Software Systems
Off: Prestige Opal,146 Infantry Road,Blore - 560001  Ph:+91-080-2286390/1/2

Henning Schulzrinne <[email-masked]> on 11/25/99 04:36:15 AM

To:   Jonathan Rosenberg <[email-masked]>
cc:   [email-masked], [email-masked]
Subject:  Re: Line Folding + Grammar strictiness {RESEND}

Jonathan Rosenberg wrote:

> There is a general guideline about being forgiving on reception, but you
> are correct. Really, tag should just be a token, same with Call-ID. The
> semantics should say that they must be unique, and that a suggestion is
> to use a UUID or something of the form id@host, but we should not impose
> that at a syntactic level.
>
For the call-id, I disagree. This should be specified, since any other
form is invalid. We want to specify a user@host form to decrease the
likelihood of collisions. (One reason we might want to reconsider the
Call-ID form is to avoid revealing host information, but then we better
come up with a reasonable alternative.)
--
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 25 Nov 1999 09:04:22 -0500

> doc stating that Call-Id=token should

I tend to agree.

> tabs in front of messages (not folds !) - guess this could be a form of

That's plain wrong and will not interwork with other implementations.
This stack vendor will figure this out pretty quickly...

> message  protocol and at interops we have more complex issues to worry

Clearly, implementations should stick to what's allowed in the spec in
sending requests. However, being overly picky for syntax in processing
requests is not advantageous from a customer perspective. You get the
following:

C: "My aunt is trying to call me but she gets this weird error message."

CS: "Your aunt's phone is broken."

C: "But she can call all her other relatives. Maybe I should buy the
same phone that they have."

Since the customer can't fix the problem, his or her implementation
should make a good-faith effort to be generous. Bake-offs like the one
in Richardson are then used to figure out who is violating the spec and
who isn't. It would also be nice if testers in magazines and such would
pay attention to this, but this is probably asking too much. (Despite
the fairly dismal history of protocol conformance testing, I would even
argue that a minimal set of "safety" tests would not hurt in the
Internet environment. It would prevent a lot of the gratutious HTML
incompatibility between, say, IE and Netscape.)

The current SIP syntax tries to adhere to "standard" Internet text
protocol practice, while 
providing a canonical form that people should use to minimize
interoperability problems with "lazy" implementations.