Subject: [Sipping] SIPPING WG Status

From: "Mary Barnes" <[email-masked]>
Date: Fri, 20 Jul 2007 06:59:09 -0500

Hi all,

Here's the current status of SIPPING WG chartered items, with a few
highlights summarized.   
The links to the details are at the end.

Regards, 
Mary 
SIPPING WG co-chair 
========================================================================
========

Docs currently undergoing WGLC: 
-------------------------------
- None. 

Docs having completed WGLC (since June 20th): 
---------------------------------------------

- draft-ietf-sipping-config-framework-12 (Extended WGLC ended 9 July
2007)
Token: Editor, Design Team, WG 
Reviewers: John Elwell, Roni Even, Dave Robbins, Shida Schubert

Docs planned for WGLC during August/Sept 2007: 
-----------------------------------------------
- draft-ietf-sipping-sip-offeranswer (WGLC 13 Aug - 3 Sept 2007)
Token: Doc editor (Takuya Sawada) to incorporate any feedback. WG to
provide feedback and
       individuals to volunteer as reviewers (one currently: Byron
Campen)
       
- draft-ietf-sipping-nat-scenarios (WGLC 20 Aug - 10 Sept 2007)
Token: Doc editor (Chris Boulton) to incorporate any feedback. WG to
provide feedback. 
Current reviewers: Guarav Kuhlshreshtha, Vijay Gurbani, Spencer Dawkins

========================================================================
 
Links to information on Softarmor:
-----------------------------------
http://www.softarmor.com/sipping/process/review_procedure.html (root
directory for reviews/process) 

http://www.softarmor.com/sipping/process/wg-review/sipping-rt.html 
(sorted by Review due date - most useful for WG to know what they should
be reviewing now) 

http://www.softarmor.com/sipping/process/wg-review/sipping-rt-rev-due.ht
ml
(sorted by revision due date - most useful for doc editors to know when
their next update is expected) 

http://www.softarmor.com/sipping/process/wg-review/sipping-rt-wglc.html 
(sorted by WGLC dates - most useful for tracking official WG milestones)
(Note: I've only listed the docs that need to go through WGLC in this
version for clarity/simplicity)

http://www.softarmor.com/sipping/process/wg-review/sipping-rt-editor.htm
l
(sorted by document editor - most useful for document editors to know
how to prioritize work) 

_______________________________________________
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 15:54:23 +0300

Hi,

I realize that the WGLC ended a couple of weeks ago, but since the draft
is on the agenda next week, I thought to provide some comments:

- In general I pretty much agree with the comments made by John Elwell
and Shida Schubert. The draft will still need some work to make it
clearer what the *implementors* actually need to do. At the moment this
is to some extent hidden within the 60+ pages.

Here are some specific questions I have:

- I think the most valuable part of the configuration would be the "User
Profile". However, it did not become clear to me where a UA should
address the SUBSCRIBE request if it wants to retrive the user profile.
In fact, Section 6.1.5 states:

   This framework does not specify any discovery mechanisms
   for this profile type.  Unless configured, the device cannot, and
   MUST NOT, request the user profile.

I find this weird since I think this would the most important thing that
this draft should specify, i.e. if a SIP client has user's AoR, how does
it retrieve the configuration related to that AoR. My proposal would be
to use a non-SIP mechanism (such as proposed in
draft-veikkolainen-sipping-app-config) or if one wants to use SIP, can't
we specify that the SUBSCRIBE is always addressed to user's own AoR and
the SIP proxies use the event header to forward it to the correct place?

- It is not clear to me how config-framework interacts with SIP Outbound
and Outbound proxy discovery. Is this currently explained somewhere? I
remember it was discussed a long time ago but I have lost the track on
that. My understanding is that in Outbound the flow/connection with the
outbound proxy is created within REGISTER transaction. In
config-framework my understanding is that the first thing the UA needs
to do is to send SUBSCRIBE. Is there some kind of chicken-and-egg issue
here or am I just confused?

- Is there some reason why profile-type Event header parameter is
needed? I thought it would be possible to see already from the To header
or Request-URI what type of profile is seeked for. I thought also that
the MIME-types used for different purposes could be different, but I'm
not sure if that's the case. 

Regards,
	Markus

---

From: [email-masked]
Date: Fri, 20 Jul 2007 11:19:13 -0400

From: <[email-masked]>

   I find this weird since I think this would the most important thing that
   this draft should specify, i.e. if a SIP client has user's AoR, how does
   it retrieve the configuration related to that AoR.

I'm no expert in this, but my experience with SIP PBX's suggests that
the client generally does not know its AOR; one of the primary
configuration issues is "How do you tell the phones their AORs?"  That
sort of user-specific information is in the other configuration
documents.

IIRC, the intention of "user profile" is in a situation where a single
person may use one or more UAs, but switch them between service
providers.  Then the "user profile" address is configured into the UA
by the user directly; it overlays the service providers' profiles to
provide portable customization on the user's behalf.

Dale

---

From: [email-masked]
Date: Fri, 20 Jul 2007 11:49:56 -0400

Hi, 

I'd like to understand the status of the App Interaction Framework doc. 
Most recent I believe is draft-ietf-sipping-app-interaction-framework-05.  
According to the I-D Tracker tool, the spec is in the RFC Editor's queue, 
meaning it is up for publication.  Given most recent rev is 2005, this 
seems odd.  According to RFC Editors Queue, it appears to be waiting for a 
dependency on SIP GRUU, which in turn I believe is near completion (now in 
IESG Last Call).   Correct? 

So, is it safe to assume that once GRUU completes, that the App 
Interaction Framework will also go to RFC in short order? 

Cheers,
Peter
. 

"Mary Barnes" <[email-masked]>
20.07.07 07:59
 
        To:     <[email-masked]>
        cc:     Gonzalo Camarillo <[email-masked]>
        Subject:        [Sipping] SIPPING WG Status

Hi all,

Regards, 
Mary 
SIPPING WG co-chair

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 20 Jul 2007 17:45:40 -0400

inline.

[email-masked] wrote:
>  Most recent I believe is 
> draft-ietf-sipping-app-interaction-framework-05.   According to the I-D 
> Tracker tool, the spec is in the RFC Editor's queue, meaning it is up 
> for publication.  Given most recent rev is 2005, this seems odd. 
>  According to RFC Editors Queue, it appears to be waiting for a 
> dependency on SIP GRUU, which in turn I believe is near completion (now 
> in IESG Last Call).   Correct?  

Yes. Its been sitting waiting on GRUU for a LOOOONNNNGGG time.

> Interaction Framework will also go to RFC in short order?  

Yes.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Fri, 20 Jul 2007 23:54:33 +0200

GRUU is with the IESG, but it has progressed beyond IESG last call (no comments received) to IESG evaluation.

"The document is now (finally!) being formally reviewed by the entire IESG. Documents are discussed in email or during a bi-weekly IESG telechat. In this phase, each AD reviews the document and airs any issues they may have. Unresolvable issues are documented as "discuss" comments that can be forwarded to the authors/WG. See the description of substates for additional details about the current state of the IESG discussion. "

I suspect you will find this one gets addressed fairly quickly.

Regards

Keith

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]] 
> Sent: Friday, July 20, 2007 10:46 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: Status of SIPPING App Interaction Framework (Re: 
> [Sipping] SIPPINGWG Status)
> 
> inline.
> 
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments of core SIP
>

---

From: <[email-masked]>
Date: Wed, 25 Jul 2007 06:13:29 +0300

Hi Dale,

See below. 

Dale wrote:
>I'm no expert in this, but my experience with SIP PBX's 
>suggests that the client generally does not know its AOR; one 
>of the primary configuration issues is "How do you tell the 
>phones their AORs?"  That sort of user-specific information is 
>in the other configuration documents.
>
>IIRC, the intention of "user profile" is in a situation where 
>a single person may use one or more UAs, but switch them 
>between service providers.  Then the "user profile" address is 
>configured into the UA by the user directly; it overlays the 
>service providers' profiles to provide portable customization 
>on the user's behalf.
>

The configuration problem I'm interested in is this:

A user creates an account with SIP service provider X. By the end of
that process the user is told what her AoR is (say, [email-masked])
and what her digest password is. Based on that information the user
should be able to retrieve the rest of her configuration (outbound
proxies, XCAP root URI, conference factory URI, whatever). To my
understanding all this would be part of the "user profile", since it is
not definitely part of "local network profile" or "device profile". 

Although the config-framework draft is very verbose, it is not entirely
clear to me how this works. What is clear is that DNS queries are
addressed to domainX.com to find the proxies to talk to (I sent a
separate mail on the issue of how to deal with those proxies when the
UAC is behind a NAT and needs to use sip-outbound techniques to get the
NOTIFYs). After that a SUBSCRIBE is sent, but what is put to Request-URI
and To header is not specified to my understanding. I think this should
be normatively specified in the draft, if it's there I missed it. I
would suggest to address the SUBSCRIBE to user's own AoR. Having to
manually configure yet another URI seems suboptimal.

Markus

---

From: [email-masked]
Date: Tue, 24 Jul 2007 23:40:31 -0400

Although the config-framework draft is very verbose, it is not entirely
   clear to me how this works.

It's certainly worth working on, but I want to note that this is *not*
a scenario in the PBX environment.  Centralized configuration systems
are usually in environments where the central manager "owns" the
endpoint device.

In the scenario you describe, you would have to assume that the
service provider knows what brand of endpoint the user is using in
order to prepare configuration information for it at all.

Dale

---

From: <[email-masked]>
Date: Wed, 25 Jul 2007 07:05:20 +0300

Hi Dale,

Dale wrote:
>It's certainly worth working on, but I want to note that this 
>is *not* a scenario in the PBX environment.  Centralized 
>configuration systems are usually in environments where the 
>central manager "owns" the endpoint device.
>

Even in PBX environments there are scenarios where AoR is not bound to a
device but to a person. Compare to e-mail.

>In the scenario you describe, you would have to assume that 
>the service provider knows what brand of endpoint the user is 
>using in order to prepare configuration information for it at all.
>

Don't we have to assume that in all scenarios if we don't have
configuration objects that are standardized and supported by different
UA vendors. In that case the UA will have to indicate the object type it
understands and/or identify its "model". 

Markus

---

From: "Stephen Sprunk" <[email-masked]>
Date: Tue, 24 Jul 2007 23:42:46 -0500

Thus spake <[email-masked]>
> A user creates an account with SIP service provider X. By the
> end of that process the user is told what her AoR is (say,
> [email-masked]) and what her digest password is. Based
> on that information the user should be able to retrieve the rest
> of her configuration (outbound proxies, XCAP root URI,
> conference factory URI, whatever). To my understanding all this
> would be part of the "user profile", since it is not definitely part
> of "local network profile" or "device profile".

That's a useful scenario for user-provided devices, but that brings the 
problem that the data model for the profile itself is unspecified, which 
means the service provider must be able to dynamically generate 
model-specific profiles for every device ever made.  That's tough.

It also assumes that entering the AOR is feasible.  That's probably the case 
on PCs/PDAs/smartphones, but getting users to correctly enter a URI via a 
standard 12-key telephone is troublesome.  It would take my mother an hour 
to do that.  Heaven help the secretary with 20+ lines (e.g. BLA) on their 
device...

The scenario I'm most interested in is where the user tells the service 
provider the device ID (in our case, the MAC address, which is printed on 
the box and phone itself) and type, and the SP/PBX generates configuration 
information that includes the AOR(s).  If user-provided, ideally the device 
would learn the server to query via DHCP.  If purchased from the SP (or 
along with a PBX), it would come preconfigured with the server details.

> Although the config-framework draft is very verbose, it is not
> entirely clear to me how this works.

I agree.  I _think_ I can extrapolate what I need from the two examples, 
after referencing the verbose explanatory text, but I find it amazing that 
there's 64 pages of explanation but only three actual SIP messages. 
Particularly given how simple they seem to be, it seems a bit odd we need so 
much explanation on how to use them.

Someone once said, "show me your data and I won't need your code".  In this 
case, show me your call flows and I won't need explanatory text.  If the 
call flows are designed correctly, they will border on self-documenting.

S

Stephen Sprunk      "Those people who think they know everything
CCIE #3723         are a great annoyance to those of us who do."
K5SSS                                             --Isaac Asimov

---

From: [email-masked] (Juha Heinanen)
Date: Wed, 25 Jul 2007 08:58:11 +0300

> order to prepare configuration information for it at all.

i don't understand how the examples mentioned (outbound proxies, xcap
root, conference factory uri, etc) depend on the brand of a sip ua.
to me those look like generic resources that are independent on the
brand of an sip ua.

i haven't followed this thread at all, but would imagine that a sip au
would get from a configuration server, for example, an xml document that
contains all configuration information related to the subscribed sip
service and then the sip ua would decide what pieces of information it
is able to utilize.

-- juha

---

From: "Sumanth Channabasappa" <[email-masked]>
Date: Wed, 25 Jul 2007 07:48:56 -0600

Markus,

Although the config-framework draft is very verbose, it is not entirely
clear to me how this works. What is clear is that DNS queries are
addressed to domainX.com to find the proxies to talk to (I sent a
separate mail on the issue of how to deal with those proxies when the
UAC is behind a NAT and needs to use sip-outbound techniques to get the
NOTIFYs). After that a SUBSCRIBE is sent, but what is put to Request-URI
and To header is not specified to my understanding. I think this should
be normatively specified in the draft, if it's there I missed it. I
would suggest to address the SUBSCRIBE to user's own AoR. Having to
manually configure yet another URI seems suboptimal.
[S] The I-D does not specify *discovery* methods for the user's AoR.
However, any configured user AoR is used for the SUBSCRIBE to request
the user profile (the only way it can be done). If this is not clear, we
can add specific text around it. 

- S

---

From: "Sumanth Channabasappa" <[email-masked]>
Date: Wed, 25 Jul 2007 07:51:38 -0600

after referencing the verbose explanatory text, but I find it amazing
that 
there's 64 pages of explanation but only three actual SIP messages. 
Particularly given how simple they seem to be, it seems a bit odd we
need so 
much explanation on how to use them.
[S] I agree! But we have been asked to specifically add more text every
time, haven't we? :)

- S

---

From: Aki Niemi <[email-masked]>
Date: Thu, 26 Jul 2007 01:58:28 +0300

Hi Markus,

> not definitely part of "local network profile" or "device profile". 

I think that having out-of-band configuration of these types of UA
settings is a bad idea. I think the principle should be that the
protocol is self-contained in that all necessary settings to make the
protocol features usable are either learned from the DNS, or delivered
in-band, e.g., in the REGISTER response, via OPTIONS or something similar.

Cheers,
Aki

---

From: "Diego B" <[email-masked]>
Date: Thu, 26 Jul 2007 02:22:18 +0300

Hi;
You  suppose here that the UA device
already knows its domain and user-id.
Those values are preconfigured, manual configured by the user
or maybe learned from some DHCP ?.

I don't think out-of-band configuration is a bad idea if this
makes the user's life easier.

Regards
Diego B

---

From: "Sumanth Channabasappa" <[email-masked]>
Date: Wed, 25 Jul 2007 17:29:50 -0600

Hi Markus,

in-band, e.g., in the REGISTER response, via OPTIONS or something
similar.

[S] The intent is that the framework is self-contained. (Refer to the
section on identities and credentials.) Specifically, the user details
can be provided as part of the device profile. However, we do not
prohibit out-of-band mechanisms, if someone implements them.

- S

---

From: <[email-masked]>
Date: Thu, 26 Jul 2007 18:19:40 +0300

Diego: Yes, in my use case I expect that the UA know user's AoR. What
I'm envisioning is some kind of config dialog where the user needs to
enter the AoR and digest password, and the rest is obtained
automatically. The config-framework defines a way to learn the AoR too
as part of the device profile, but that won't work in all cases. But
having the user just give the AoR + password is already much better than
having her input all kinds of weird parameters that typical UA
configuration wizards (including ours) contain.

Aki: I'm not sure what you mean here, since the config-framework is
indeed an inband mechanism, based on SIP SUBSCRIBE and NOTIFY. I'm just
trying to clarify how it would work in detail in the case I'm
presenting, which I expect to be quite common.

Markus

>From: ext Diego B [mailto:[email-masked]] 
>Sent: 26 July, 2007 02:22
>To: Niemi Aki (Nokia-TP-MSW/Helsinki)
>Cc: [email-masked]
>Subject: Re: [Sipping] Comments/Questions on 
>sipping-config-framework-12
>
>Hi;
>> > that process the user is told what her AoR is (say, 
>> > [email-masked]) and what her digest password is. Based on that 
>> > information the user should be able to retrieve the rest of her 
>> > configuration (outbound proxies, XCAP root URI, conference factory 
>> > URI, whatever). To my understanding all this would be part of the 
>> > "user profile", since it is not definitely part of "local 
>network profile" or "device profile".
>>
>> 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
>>
>
>
>This list is for NEW development of the application of SIP Use 
>[email-masked] for questions on current sip

---

From: "Diego B" <[email-masked]>
Date: Thu, 26 Jul 2007 18:49:53 +0300

Hi;
I agree that at minimum any user can enter his AoR and password like
in any IM or e-mail application (e-mail is actually more complicated
with incoming mail server, outgoing email server server protocol, etc
).
But just that. no nay other parameter ( yes, like the complicated
property pages from some SIP enabled mobile phones).

>From there on, the UA can fetch any information.

Regards
Diego B

---

From: Aki Niemi <[email-masked]>
Date: Thu, 26 Jul 2007 23:52:27 +0300

> presenting, which I expect to be quite common.

My point is that the few additional parameters a UA needs to enable for
the most common features can just as easily be returned in the response
to a REGISTER or OPTIONS request. Maybe this could be called inner-band
configuration. ;)

Additionally, I think the outbound proxy really should be learned from
the DNS. I think we should ask Erkki to wipe the dust off of his draft
and resubmit.

Cheers,
Aki

---

From: [email-masked]
Date: Thu, 26 Jul 2007 18:34:37 -0400

From: "Sumanth Channabasappa" <[email-masked]>

Assuming that you want your device to interoperate successfully, I can
*assure* you that you cannot.  "Coding to example" *always* leads to
very long debugging cycles.

   after referencing the verbose explanatory text, but I find it
   amazing that there's 64 pages of explanation but only three actual
   SIP messages.  Particularly given how simple they seem to be, it
   seems a bit odd we need so much explanation on how to use them.

Compare a page of C code to the ANSI C standard.  Which is longer?
Which allows you to know exactly what can and cannot be done in C?

Dale

---

From: [email-masked]
Date: Thu, 26 Jul 2007 18:35:46 -0400

From: [email-masked] (Juha Heinanen)

Yes, UAs do get such documents.  But those documents have a different
format for every brand of UA, and often, every *model* of every brand.

Dale

---

From: [email-masked] (Juha Heinanen)
Date: Fri, 27 Jul 2007 09:28:58 +0300

> format for every brand of UA, and often, every *model* of every brand.

sorry, but i though that the config framework document would standardize
this xml document format so that all vendors/models would use the same
thing in the future.

-- juha

---

From: "Sumanth Channabasappa" <[email-masked]>
Date: Fri, 27 Jul 2007 07:35:24 -0600

Juha,

[S] The current config. framework does not standardize data, but
provides recommendations when required. There is absolutely a need to
specify standard profile data (IMHO), and there are related I-Ds, but
they are all dependent on the config. framework for completion.

- S

---

From: [email-masked]
Date: Fri, 27 Jul 2007 22:24:35 -0400

No, but the config framework does standardize how the UA discovers and
fetches the configuration documents, which is even more important.

Dale