Subject: [Sipping] Two configuration drafts

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 8 Jul 2007 11:15:15 -0400

A little late, but we now have two configuration drafts. Abstracting  
a bit and ignoring details, my perception is that the principal  
difference is that one (sipping-config) is SIP-followed-by-HTTP,  
while the other is HTTP-possibly-followed-by-SIP (event  
notification). I'll call them SIP-HTTP and HTTP-SIP for short. For  
the latter, I'm extrapolating a bit, since the -00 draft isn't as  
complete.

It seems clear that both can work and have roughly the equivalent  
capabilities. However, I think there are trade-offs:

SIP-HTTP makes subscribing to the User profile easier, since it's  
just an AOR. HTTP-SIP needs a translation step, e.g., via NAPTR. The  
other modes seem relatively similar, as they rely on other protocols  
to convey URLs, such as DHCP.

HTTP-SIP seems easier to implement. Many systems won't need event  
notification, and thus can do a trivial HTTP retrieval, without the  
three step process (SUBSCRIBE transaction, wait some indeterminate  
amount of time for NOTIFY, then HTTP).

HTTP-SIP generalizes to non-SIP systems if you skip the SIP phase or  
replace it with another notification mechanism.

Since both approaches end up in the same place, namely using HTTP to  
retrieve the actual data, one wonders if it wouldn't be helpful to  
allow for both, simply by defining an appropriate U-NAPTR record that  
allows direct access to the HTTP data, by translating the SIP AOR to  
an HTTP URL.

As a side note, I admit that I still find draft -12 a very tedious  
and difficult read, with lots of abstract machinery that mainly  
serves to obscure the stuff that implementors actually need to do.

Henning

_______________________________________________
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: <[email-masked]>
Date: Fri, 20 Jul 2007 16:22:42 +0300

Henning,

I think what you wrote is a pretty fair characterization of the two
proposals. The main motivation for the authors of
draft-veikkolainen-sipping-app-config (what you call HTTP-SIP) is quite
well captured within your two points below:

>HTTP-SIP seems easier to implement. Many systems won't need 
>event notification, and thus can do a trivial HTTP retrieval, 
>without the three step process (SUBSCRIBE transaction, wait 
>some indeterminate amount of time for NOTIFY, then HTTP).
>
>HTTP-SIP generalizes to non-SIP systems if you skip the SIP 
>phase or replace it with another notification mechanism.

In draft-veikkolainen our main focus is to address the following
problem: When a user enters her SIP AoR (and digest password), how can
the SIP client retrive the configuration related to the user and her
service provider so that the client starsts to function. We did not
focus that much on "local network" or "device" spefic configuration (as
we haven't seen a real-word need for them so far), although they can be
supported. The difference is just the configuration comes from a
different domain and is possibly encoded within a different type of an
object.

In addition to SIP UA config we wanted to have something which can be
used to e.g. POP client configuration. The problem with SIP in that case
is that it is not realistic to assume e-mail providers to run SIP infra
for configuration purpose, but they all definitely have DNS and a web
server. Also, integrating HTTP to an e-mail client seems more realistic
than SIP.

In our experience real-time notifications on config changes are not
required in most deployments. Config information tends to be quite
stable, so poll works. In case notifications are needed (this has been
stressed primarily from the enterprise environment), we can use the SIP
event package as defined in sipping-config as an optional component. It
would be useful if sipping-config explicitely defined where to address
the subscription based on an AoR for the user profile.

>Since both approaches end up in the same place, namely using 
>HTTP to retrieve the actual data, one wonders if it wouldn't 
>be helpful to allow for both, simply by defining an 
>appropriate U-NAPTR record that allows direct access to the 
>HTTP data, by translating the SIP AOR to an HTTP URL.

I would be happy with this.

Since the approach in draft-veikkolainen is a bit wider than just SIP UA
configuration, the question is that where it should be developed forward
in the IETF, though. SIP is sorely requiring a configuration solution,
but similarly a more generic application configuration mechanism is
missing in the IETF (I suppose ACAP is a bit outdated by now and XCAP
addresses a slightly different problem, i.e. data manipulation).

I suppose this whole discussion will take place in the SIPPING session
on Tuesday. We are also trying to get a slot in App Area open meeting on
Monday morning to get some feedback from there.

Regards,
	Markus 

>-----Original Message-----
>From: ext Henning Schulzrinne [mailto:[email-masked]] 
>Sent: 08 July, 2007 18:15
>To: sipping
>Subject: [Sipping] Two configuration drafts
>
>A little late, but we now have two configuration drafts. 
>Abstracting a bit and ignoring details, my perception is that 
>the principal difference is that one (sipping-config) is 
>SIP-followed-by-HTTP, while the other is 
>HTTP-possibly-followed-by-SIP (event notification). I'll call 
>them SIP-HTTP and HTTP-SIP for short. For the latter, I'm 
>extrapolating a bit, since the -00 draft isn't as complete.
>
>It seems clear that both can work and have roughly the 
>equivalent capabilities. However, I think there are trade-offs:
>
>SIP-HTTP makes subscribing to the User profile easier, since 
>it's just an AOR. HTTP-SIP needs a translation step, e.g., via 
>NAPTR. The other modes seem relatively similar, as they rely 
>on other protocols to convey URLs, such as DHCP.
>
>HTTP-SIP seems easier to implement. Many systems won't need 
>event notification, and thus can do a trivial HTTP retrieval, 
>without the three step process (SUBSCRIBE transaction, wait 
>some indeterminate amount of time for NOTIFY, then HTTP).
>
>HTTP-SIP generalizes to non-SIP systems if you skip the SIP 
>phase or replace it with another notification mechanism.
>
>Since both approaches end up in the same place, namely using 
>HTTP to retrieve the actual data, one wonders if it wouldn't 
>be helpful to allow for both, simply by defining an 
>appropriate U-NAPTR record that allows direct access to the 
>HTTP data, by translating the SIP AOR to an HTTP URL.
>
>As a side note, I admit that I still find draft -12 a very 
>tedious and difficult read, with lots of abstract machinery 
>that mainly serves to obscure the stuff that implementors 
>actually need to do.
>
>Henning
>
>
>
>
>This list is for NEW development of the application of SIP Use 
>[email-masked] for questions on current sip

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 20 Jul 2007 12:17:55 -0400

I think the U-NAPTR approach generalizes. For example, it works for  
mailto: or maybe even IMAP URLs (RFC 2192). However, I think much of  
the SMTP and IMAP configuration can simply be handled by doing SRV  
for the protocol, as configuring the protocol endpoint is the main  
configurable item.