Subject: Incremental Update

From: Christoph Renner <[email-masked]>
Date: Tue, 15 Feb 2000 11:24:15 +0100

Is there a way to incrementally update (i.e. delete) keywords in service

registrations? Obviously, it might be possible to re-register (with F
flag set). Can  that be done incrementally?
Imagine a printer with a keyword "paper-congestion". As soon as a
congestion occures, the SA sends an incremental update to the DA with
the added keyword. When the congestion got fixed, the SA would like to
have that keyword removed again from the service registration.
But I cannot find that there is a way to do that as an incremental
update. Did I miss something?

Thanks,
Christoph

---

From: Erik Guttman <[email-masked]>
Date: Tue, 15 Feb 2000 13:17:21 +0100 (MET)

Christoph,

> flag set). Can  that be done incrementally?

To incrementally add to a registration, register the same URL, scope, 
SPI, service type and language, but with the new attribute.  In this
subsequent registration the 'F' flag is *not* sent.  That's how the
SA signals to the DA that the registration is an update not a full
re-registration.

To incrementally delete an attribute from a registration, the SA sends
a SrvDereg message with an attribute tag list set to the attributes to
be deleted.

> update. Did I miss something?

Yes.  You should look closer at Section 9.3 of RFC 2608 for incremental
registration rules and 10.6 where service deregistration is discussed.
 
   The <tag-list> is a <string-list> of attribute tags to deregister as
   defined in Section 9.4.  If no <tag-list> is present, the SrvDeReg
   deregisters the service in all languages it has been registered in.
   If the <tag-list> is present, the SrvDeReg deregisters the attributes
   whose tags are listed in the tag spec. 

Note there are some complications to this:

 1. DAs can advertise a 'min-refresh-interval'.  SAs should not not
    do refreshes more often than this.  This allows DAs to control
    SA behavior to some extent to provide scalable operation which
    does not require SA reconfiguration.  Note different DAs may have
    different values, but as long as you use the largest 'min' you will
    satisfy all DAs.

 2. Updates and incremental deregistrations require authentication
    blocks to prevent malicious tampering with legitimate service
    advertisements.

 3. If updates or deregistrations are sent for services which have
    expired or were never registered, the DA will reject the Srv/De/Reg
    message.

 4. DAs may reject refreshes (as coming too often), the DA may be busy, 
    etc.  SAs then may need to retry later.

> Christoph

Here is an example.

Printer SA 

  Service URL = U, Service type = T, Scope List = SL, SPI = S, Lang = L1
  (let's call this {U,T,SL,S,L1})
  Attributes = (A=one,two),(B=TRUE)

        Message                                         Attributes for U
        -----------------------------------------=--    -----------------
1 SA -> SrvReg {U,T,SL,S,L1}, Attrs, Fresh=1   -> DA  
     <- SrvAck                                 <- DA    (A=one,two),
                                                        (B=TRUE)
2 SA -> SrvReg {U,T,SL,S,L1}, "alert", Fresh=0 -> DA        
     <- SrvAck                                 <- DA    (A=one,two),
                                                        (B=TRUE),alert
3 SA -> SrvReg {U,T,SL,S,L1}, "(A=foo)", Fresh=0 -> DA     
     <- SrvAck                                 <- DA    (A=foo),
                                                        (B=TRUE),alert
4 SA -> SrvDeReg {U,SL,S,L1}, "B,alert"        -> DA
     <- SrvAck                                 <- DA    (A=foo)
5 SA -> SrvReg {U,T,SL,S,L1}, "alert", Fresh=1 -> DA
     <- SrvAck                                 <- DA    alert

1 is an initial registration
2 is an update, which adds a keyword "alert" to the registration. 
  This is analogous to the "paper-congestion" keyword above.
3 is an update, which changes the value of the attribute A.
  Updates *replace* the prior values of an attribute with the same tag.
  Note that more than one attribute could be in the attribute list of
  the update, I just made it simple for the example.
4 is an incremental deregistration.  The registration for U is still
  advertised by the DA since the SrvDereg contained an attribute list.
  The modified attribute list remotes both B and alert.
5 is a re-registration.  It completely replaces the previous registration
  since the 'F' flag is not set.

Please note that if more than one language is used (say "en" and "fr", 
English and French), then all the steps above would have to be done for
both languages.  That is, 20 messages instead of 10 would be sent (counting
the SrvAcks).

Erik