Subject: [SIP] nit-pickey JAIN-SIP questions

From: "M. Ranganathan" <[email-masked]>
Date: Tue, 17 Oct 2000 12:51:13 -0400

Hi  Chris / other authors of the JAIN-SIP spec !

The following questions may be a little nit-pickey.  However, I prefer
to be minimialistic  when defining  a spec:

1. I know that the sip RFC talks about different header classifications
such as GeneralHeader, EntityHeader, RequestHeader and ResponseHeader.
However, in my opinion  (perhaps this is a wrong opinion - in which case
please educate me on this one),
this is more of a logical separation than a necessary one for any
implementation to follow. Why does the API  have to divide things the
same way?  ( I am suggesting shrinking the class hierarchy by 1 level. -
no big deal, just minimialism at work)

2.  The Header structure in the JAIN API  has  public final integers
that are basically identifiers for the classes that inherit from it.  I
assume the intent is to let the client query the type of class so that
it can know whether the Header is a GeneralHeader, RequestHeader etc.
Why do you need the integers to identify the type of header a client can
use introspection to find the class. This way you can also eliminate
getHeaderType() (rely on the caller to use introspection).

3. Does the token value in various headers refer to the string from
which the header was generated?

More questions to follow while I ponder implementation....

Regards

Ranga

--
M.Ranganathan
NIST Advanced Networking Technologies Group,
100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899.
Tel: 301 975 3664 Fax: 301 590 0932

ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÒ ùšŠX§‚X¬µ"þX¬¶ÏÛzYÿ•¦ìýÊ&†ÛiÿÿåŠËlý·¥—ùZnÏÜ¢oæj)fjåŠËbú?

---

From: Chris Harris <[email-masked]>
Date: Tue, 17 Oct 2000 19:20:32 +0100

Some very good questions indeed!

> no big deal, just minimialism at work)

The main reason for these four classes is to represent extension headers
which are not covered by the API header classes. Let's say the underlying
implementation knows about a general header that is not in the API. The
default behaviour is to regard an unrecognised header as an entity header,
but surely the underlying implementation should be able to say to the
application (which may or may not understand this header) which type of
header it is. (This applies from the application to the implementation too).
Also, an implementation may indicate to an application that a particular
unrecognised header is a request header, and so should not be included in a
response.

These reasons may not warrant the extra level in the hierarchy - see next
response...

> getHeaderType() (rely on the caller to use introspection).

Introspection would certainly work perfectly - I just wanted to have a more
convenient way for the user to determine the header type. But, as I
understand it introspection is not exactly cheap compared to a simple
accessor method call. Looking at it now - the getHeaderType method on the
Header class makes the four classes obsolete. (Unless introspection is
preferable in an API, in which case the getHeaderType method should go)

Actually this makes me realise something about the Message and Header
classes - the constructors pass the Message's method or Header's token (see
below) to the super constructor. The API internally uses the getMethod and
getToken methods to determine the message or header type, rather than
introspection - which assumes that the implementor or user will use the
correct class (e.g. InviteMessage rather than RequestMessage, CallIdHeader
rather than Header or GeneralHeader). I used these methods for performance
reasons, but now that I think about it, there is nothing stopping them from
using the wrong class - so if a RequestMessage object is encountered with a
method "INVITE" it is incorrect to assume that this is also an InviteMessage
object - introspection is the only real way to know which class it is using.
If introspection reveals that it uses the correct class that's OK - cast to
InviteMessage, but if it's not, then what? - should you create an
InviteMessage object based on the RequestMessage object so you can use the
extra methods?

> which the header was generated?

The token is the name of the header e.g. "Call-Id" - "token" was a poor
choice - perhaps "OptionTag" would be more appropriate?

> Hƒæj)bž b²Ôˆ>X¬¶ÆÞ–YZnÇ(šm§ÿåŠËlmée•¦ìr‰¿™¨¥™©ÿ–+-ŠwèþÈ©

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