> Here is a rough draft (in i-d format) of my proposal. Since
> getnameinfo API is defined in POSIX (not in IETF), i would like to
> collect comments from here, reflect them into the draft, and then send
> it out to POSIX community. any comments are welcome.
> (i'll
Here is a rough draft (in i-d format) of my proposal. Since
getnameinfo API is defined in POSIX (not in IETF), i would like to
collect comments from here, reflect them into the draft, and then send
it out to POSIX community. any comments are welcome.
(i'll
Peter Lei <[EMAIL PROTECTED]> writes:
> >>But this reminds me; doesn't SCTP use the same port number space
as TCP?
Not anymore.
> > basically the same space, but they do have separate entries on
> > /etc/services and http://www.iana.org/assignments/port-numbers.
> > for instance,
ED] On
> Behalf Of Jun-ichiro itojun Hagino
> Sent: Monday, December 15, 2003 4:28 PM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: Re: getnameinfo and various protocol types
>
>
> > > Actualy, RFC2960 explictily states tha
Jun-ichiro itojun Hagino wrote:
>
> > And define NI_TCP, which is also the default if none is specified?
> > I'd also propose deprecating the default, to get everyone in the habit
> > of specifying something.
>
> deprecating the default would break source-code level backward
> com
> > Actualy, RFC2960 explictily states that "All current TCP ports shall be
> > automatically reserved in the SCTP port address space." in the IANA
> > considerations section.
>
> That was what I remebered. If this indeed means that there will not
> be any conflicting usage in the future (which th
> Actualy, RFC2960 explictily states that "All current TCP ports shall be
> automatically reserved in the SCTP port address space." in the IANA
> considerations section.
That was what I remebered. If this indeed means that there will not
be any conflicting usage in the future (which the above text
Jun-ichiro itojun Hagino wrote:
SCTP supports both SOCK_DGRAM, SOCK_STREAM as well as SOCK_SEQPACKET.
SOCK_STREAM sounds odd since SCTP doesn't provide a byte stream service - it
provides a service that has explicit message boundaries.
SCTP do provide three models (SOCK_xx).
draf
> > SCTP supports both SOCK_DGRAM, SOCK_STREAM as well as SOCK_SEQPACKET.
>
> SOCK_STREAM sounds odd since SCTP doesn't provide a byte stream service - it
> provides a service that has explicit message boundaries.
SCTP do provide three models (SOCK_xx).
draft-ietf-tsvwg-sctpso
> SCTP supports both SOCK_DGRAM, SOCK_STREAM as well as SOCK_SEQPACKET.
SOCK_STREAM sounds odd since SCTP doesn't provide a byte stream service - it
provides a service that has explicit message boundaries.
> DCCP should be SOCK_DGRAM only, if i understand correctly.
Also odd; you mea
On Dec 12, 2003, at 1:15 AM, Jun-ichiro itojun Hagino wrote:
now we have couple of new transport protocols coming, such as SCTP
and
DCCP. how can we support service name lookup for those? i.e.
how can we tell getnameinfo(3) to use "sctp" or "dccp" for the 2nd
argument of getservbyport(3)?
> > > now we have couple of new transport protocols coming, such as SCTP and
> > > DCCP. how can we support service name lookup for those? i.e.
> > > how can we tell getnameinfo(3) to use "sctp" or "dccp" for the 2nd
> > > argument of getservbyport(3)?
> > >
> > > my proposal:
> > >
> [EMAIL PROTECTED] wrote:
> >
> > my proposal:
> > define NI_UDP as replacement of NI_DGRAM. deprecate NI_DGRAM (keep
> > it as an alias to NI_UDP is okay). define NI_SCTP, NI_DCCP and such.
> > these three are mutually exclusive, and if more than one is specified
> > it would cause EAI_FAIL.
>
> Hi Itojun,
> > my proposal:
> > define NI_UDP as replacement of NI_DGRAM. deprecate NI_DGRAM (keep
> > it as an alias to NI_UDP is okay). define NI_SCTP, NI_DCCP and such.
> > these three are mutually exclusive, and if more than one is specified
> > it would cause EAI_FAIL.
> Agree! I assume "and such" implies that NI_TCP will be defined too,
> which is still the default if nothing is specified in the call (for
> backward compatibility?)
yup, NI_TCP would have a value of 0 and is still a default.
itojun
-
> > now we have couple of new transport protocols coming, such as SCTP and
> > DCCP. how can we support service name lookup for those? i.e.
> > how can we tell getnameinfo(3) to use "sctp" or "dccp" for the 2nd
> > argument of getservbyport(3)?
> >
> > my proposal:
> >
> now we have couple of new transport protocols coming, such as SCTP and
> DCCP. how can we support service name lookup for those? i.e.
> how can we tell getnameinfo(3) to use "sctp" or "dccp" for the 2nd
> argument of getservbyport(3)?
>
> my proposal:
>
We should do this as addendum to 3493 for sure.
/jim
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> Behalf Of [EMAIL PROTECTED]
> Sent: Thursday, December 11, 2003 3:44 AM
> To: [EMAIL PROTECTED]
> Subject: getnameinfo and various protocol types
>
>
>
[EMAIL PROTECTED] wrote:
getnameinfo(3) specification assumes that there are only two transport
protocols - tcp and udp. when performing service name lookup
it would use "tcp" if NI_DGRAM is not specified, and "udp" when
NI_DGRAM is specified.
now we have co
Hi Itojun,
> my proposal:
> define NI_UDP as replacement of NI_DGRAM. deprecate NI_DGRAM (keep
> it as an alias to NI_UDP is okay). define NI_SCTP, NI_DCCP and such.
> these three are mutually exclusive, and if more than one is specified
> it would cause EAI_FAIL.
[EMAIL PROTECTED] wrote:
>
> my proposal:
> define NI_UDP as replacement of NI_DGRAM. deprecate NI_DGRAM (keep
> it as an alias to NI_UDP is okay). define NI_SCTP, NI_DCCP and such.
> these three are mutually exclusive, and if more than one is specified
> it would cause EAI_FAIL.
And define NI_
21 matches
Mail list logo
