re: SIP API spec

[Craig Partridge <[e-mail]>]

Hi folks:

    Bob had asked for comments to him, so I sent them privately but it looks
like the document is going to be publicly debated, so here are my few cents
worth of thoughts.

Craig

E-mail: [e-mail] or [e-mail]

------- Forwarded Message

To: [e-mail] (Bob Gilligan)
Subject: re: SIP API spec
>From: Craig Partridge <[e-mail]>
Date: Mon, 25 Jan 93 19:13:01 -0800
Sender: craig


Hi Bob:

    Nice first draft.  I've got a bunch of little suggestions.

> 2.2 Implementation experience
> 
> ....
> 
> While this technique works for most existing applications, we concluded
> that it would be unworkable in the general case when we discovered that
> some applications do not set the sin_zero field of the sockaddr_in
> structure to zero.

Yucko -- but before we concede, should we recognize that the applications
need fixing anyway to handle SIP?  (Being nasty to bad application programmers
doesn't make me feel bad).

> 3.4 Setsockopt options
> 
> We define two options at the IPPROTO_IP level that can be used with
> AF_INET or AF_SIP sockets.  They have the following definitions in
> <netinet/in.h>:
> 
> #define SIP_FLOWID	0x15		/* get/set SIP flow ID */
> #define SIP_ADDRFORM	0x16		/* get/set form of returned addrs */
> 
> Using the SIP_FLOWID option via setsockopt() sets the value of the flow
> ID (a.k.a the SIP reserved field) used in all outgoing SIP packets sent
> via that socket.  Using SIP_FLOWID via getsockopt() returns the flow ID
> value given in the last setsockopt() call, not the flow ID in received
> packets.  The value of the argument to the SIP_FLOWID option is a u_long
> type.

Why would an application ever want to set the FLOWID?  I've assumed that
this is something that is done by the kernel.  Also, I assume it is not
legit to set the flow ID after connect() is called (i.e. to change flowids
on the fly).  What do setsockopt() and getsockopt() return in these cases?
EINVAL?  More generally, specifyng error return codes would be a good thing.

> 3.6 Open Issues
> 
> The API changes described here are just the beginning.  Among the
> other changes we might want to consider are:
> 
>   -	There is a type defined (in_addr) to represent a 32-bit IPv4
> 	address.  Should we define a structure to hold the 64-bit SIP
> 	address?

in_addr was a mistake -- let's not perpetuate it.

>   -	There are a number of functions (inet_addr(), inet_ntoa()) for
> 	translating IPv4 addresses to and from printable form.  Should
> 	we define similar functions for 64-bit SIP addresses?

Yes!!!

>   -	The format of the "/etc/hosts" file currently supports only
> 	IPv4 addresses.  Should we extend the format of the existing
> 	file to handle SIP addresses?  Or should we invent a file with
> 	a new name for storing SIP host addresses.

Dunno.

>   -	The name of the function gethostbyname2() might confuse
> 	people.  Should we pick a different name?

How about hostname2addr(), and hostbyaddr(), and addr2ascii()?
    <for gethostbyname(), gethostbyaddr(), inet_ntoa(), and make
    them all take an AF_* value so that they can be made address
    format independent>

Craig

------- End of Forwarded Message