Subject: [Sipping] WGLC draft-ietf-sipping-reg-event-00.txt

From: Rohan Mahy <[email-masked]>
Date: Wed, 30 Oct 2002 14:40:08 -0800

Hi Folks,

I'd like to open last call for draft-ietf-sipping-reg-event-00.txt.  
Unfortunately this draft is not in the archive yet, but it is available 
at:

http://www.jdrosen.net/papers/draft-ietf-sipping-reg-event-00.txt

(yes, I have gotten the OK to begin WGLC on this document before it 
appears in the archive)

Since the changes to this document are minor and uncontroversial (I 
believe), WGLC will close on Nov 12

many thanks,
-rohan

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "Brian Stucker" <[email-masked]>
Date: Thu, 31 Oct 2002 12:38:50 -0600

Section 4.4:

Do you think it's a good idea to have the default expiration for the
registration, and the subscription to be the same length? I could see
situations where this could cause race conditions that would cause NOTIFY
messages to intermittently fail to be sent due to the subscription and
registration naturally expiring right around the same time. 

Other comments:

What exactly is the purpose of having the ID field in the contact portion of
the NOTIFY body? Doesn't seem very useful to be a required element. Is there
any reason that you would not make this some sort of hash of the contact
element data (ie. the contact address itself)? In other words, what does the
ID field do for you that simplying keying off the data doesn't, since you
can't have two entries with the exact same contact address in the same
registration message?

Regards,

Brian

-----Original Message-----
From: Rohan Mahy [mailto:[email-masked]]
Sent: Wednesday, October 30, 2002 4:40 PM
To: [email-masked]'
Subject: [Sipping] WGLC draft-ietf-sipping-reg-event-00.txt

Hi Folks,

many thanks,
-rohan

---

From: "Brian Stucker" <[email-masked]>
Date: Thu, 31 Oct 2002 17:10:56 -0600

Ah, good eye. Yes, I missed that bit. =)
 
Thanks,
 
Brian

-----Original Message-----
From: Rohan Mahy [mailto:[email-masked]]
Sent: Thursday, October 31, 2002 4:53 PM
To: Stucker, Brian [NGC:B617:EXCH]
Cc: [email-masked]; [email-masked]'
Subject: Re: [Sipping] WGLC draft-ietf-sipping-reg-event-00.txt

Hi Brian, 

You raise a good point about using a sipfrag. Your example still does not
include the *event* however, although i suspect it would be simple to add an
event contact parameter. 

thanks, 

-rohan 

On Thursday, October 31, 2002, at 11:03 AM, Brian Stucker wrote: 

I am seriously confused.... 

Can someone explain to me why we're suggesting that we do the following: 

1. Client takes the information necessary to send a registration message and
encodes it into a SIP message for transport. 

2. Registrar decodes the registration, process it, sees that there is a
subscription for this user's registration and so... 

3. RE-ENCODES the registration information into XML, even though the client
that sent us the registration already went to the trouble of encoding nearly
all of the information we're interested in (which makes it take up extra
bytes), and sends it to the interested party. 

4. Interested party decodes the NOTIFY body, and does whatever it wants. 

Instead of going through all this trouble, why are we not following the
example of REFER and using a sipfrag? I why do we want to go through
re-encoding the expiration time, q-value, call-id, cseq, contact address,
address of record, etc., etc. in XML when I've already got parsers that can
do the job with: fewer bytes, off-loads much of the processing overhead of
encoding these things across all of the client devices instead of at a
single server somewhere, and I know that the encoding is valid because I
just decoded it. 

It's not so much concerned about the network, but CPU cycles on servers,
etc., which is non-trivial when you're processing tens or hundreds of
thousands of these messages an hour.  For the other attributes that aren't
in SIP, those can be added as a parameter in the contact, either your parser
will accept them, or not. 

For instance, in the document: 

   <?xml version="1.0"?> 

   <reginfo xmlns="urn:ietf:params:xml:ns:reginfo" 

                version="0" state="full"> 

     <registration aor="sip:[email-masked]" id="as9" 

                   state="active"> 

       <contact id="76" state="active" event="registered" 

                duration-registered="7322" 

                q="0.8">sip:[email-masked]</contact> 

       <contact id="77" state="terminated" event="expired" 

                duration-registered="3600" 

                q="0.5">sip:[email-masked]</contact> 

     </registration> 

   </reginfo> 

(578 bytes) 

Could simply be: 

t: sip:[email-masked] 

m: <sip:[email-masked]>;q=0.8;duration-registered=7322;expires=3600,
<sip:[email-masked]>;q=0.5;duration-registered=3600;expires=0 

(170 bytes) 

I've just transported every piece of information in the above message using
an already well-known message body type "sipfrag", reused my existing
parsers, did not re-encode information that was already given to me by the
client, and did it in 71% fewer bytes. 

Regards, 

Brian Stucker 

Nortel Networks 

-----Original Message----- 

To: [email-masked]' 

Hi Folks, 

at: 

appears in the archive) 

many thanks, 

-rohan