[Sip] Comments on draft-ietf-sip-outbound-05

[EKR <ekr at networkresonance.com>]

$Id: draft-ietf-sip-outbound-05-rev.txt,v 1.1 2006/10/29 19:54:58 ekr Exp $

Some mostly editorial comments.

S 1.
   Configuration Protocol).  These systems typically do not have a
   useful name in the Domain Name System (DNS), and they definitely do
   not have a long-term, stable DNS name that is appropriate for use in
   the subjectAltName of a certificate, as required by [RFC3261].

s/definitely/with high probability/ 

You can have dynamically assinge dstatic names.


   request, the proxy can later use this same network "flow", whether

s/, /--/
                                                            
   this is a bidirectional stream of UDP datagrams, a TCP connection, or
   an analogous concept of another transport protocol to forward any

s/protocol to/protocol--to/

   requests that need to go to this UA.  For a UA to receive incoming


S 3.1.
   both reach the same UA.  The registrar can use the reg-id label to
   recognize that a UA is registering after a reboot or a network

s/registering/re-registering/?


S 3.4.
I think a ladder diagram would help here.


S 4.1.
   A UA SHOULD use a UUID URN [RFC4122]. 

add to the end "as its instance ID"


S 4.2.
   UAs obtain at configuration time one or more SIP URIs representing

"At configuration time UAs obtain..."



S 6.
   comparison purposes.  A Contact header field value with an
   instance-id but no reg-id is valid, but one with a reg-id but no
   instance-id is not.  If the registrar processes a Contact header

When would instance-id but no reg-id happen?

   In addition, unless the registrar has positive knowledge that the
   topmost Path header URI is reachable from the authoritative proxy, it
   must store the flow information for the previous hop.  The registrar

s/must/MUST/


      however implementations need to be preared to receive STUN
      messages which cross a stream buffer boundary, and SIP and STUN
      messages which share the same stream buffer.

I don't understand what this means. If you mean that any time you
call read(1) you might get SIP and STUN messages intermixed, isn't
that a basic property of TCP?

-Ekr






_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip