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

From: "Brian Stucker" <[email-masked]>
Date: Thu, 31 Oct 2002 13:03:26 -0600

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-----
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,

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: Rohan Mahy <[email-masked]>
Date: Thu, 31 Oct 2002 14:53:20 -0800

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:

> 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.
>
> 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.
>
> m:  
> <sip:[email-masked]>;q=0.8;duration- 
> registered=7322;expires=3600,  
> 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
>
>
>