Subject: [Sipping] Comments on config framework draft

From: [email-masked]
Date: Wed, 22 Sep 2004 14:50:39 +0300

If you want to discuss a particular issue, please start a new email thread.

Section 2.3
------------

- "If the content is provided indirectly the
   UA SHOULD retrieve the profile from the specified URI upon receipt of
   the change notification."

The SHOULD is way too strong here. I don't have to retrieve whatever is behind the link. A MAY will suffice here.

- "A very high level data model is implied here with the separation of
   these four profile types.  Each profile type requires a separate
   subscription to retrieve the profile."

I would say that each profile type *instance* needs a separate subscription unless multiple app-id, document, etc. If I'm wrong, then there is something wrong with the description of profile types and instances.

Section 3.2
-----------

- "This package defines the following new parameters for the event
   header: "profile-name", "vendor", "model", "version", "effective-by",
   "document", "app-id".  The effective-by parameter is for use in
   NOTIFY requests only.  The others are for use in the SUBSCRIBE
   request, but may be used in NOTIFY requests as well."

What should a server so if effected-by parameter appears in a SUBSCRIBE. I say ignore.
What should a client do if other parameters appear in a NOTIFY. I say ignore.

- "The "network-user" parameter is used when subscribing for local
   network profiles.  If the value of the profile-name parameter is not
   "local", the "network-user" parameter has no defined meaning.  If the
   user has special privileges beyond that of an anonymous user in the
   local network, the "network-user" parameter identifies the user to
   the local network.  The value of this parameter is the user's address
   of record.  The SUBSCRIBE server may authenticate the subscriber to
   verify this AOR."

I don't believe this is needed. Authentication should be out of scope of this document. Also, the identity (AOR) of the user should be derived after authentication locally, no need for the network-user param.

- "The "effective-by" parameter in the Event header of the NOTIFY
   specifies the maximum number of seconds before the user agent MUST
   make the new profile effective.  A value of 0 (zero) indicates that
   the user agent MUST make the profiles effective immediately (despite
   possible service interruptions).  This gives the profile delivery
   server the power to control when the profile is effective.  This may
   be important to resolve an emergency problem or disable a user agent
   immediately."

Now can a server enforce this. If a server really wants a user to change the profile, there is no mechanism to enforce the new profile.

- "Event: sip-profile;profile-name=
      "http://example.com/services/user-profiles/users/freds.xml";
               vendor=premier;model=trs8000;version=5.5"

Something is wrong with the above example. Why is the profile name an xcap URI?

Section 3.6
-----------

- "If content indirection is used for delivering the
   profiles, the notifier does not need to authenticate the subscription
   as the profile content is not transported in the SUBSCRIBE or NOTIFY
   transaction messages."

So what? the body of the NOTIFY still contains valuable information. I think it is a bad idea to suggest that authentication is not needed. I would say authentication is always needed.

- "If the user or device is not known to the profile delivery server,
   the implementer MAY accept the subscription or reject it.  It is
   recommended that the implementer accept the subscription."

I think this is a very bad recommendation. This a a potential DoS attack on the server. The server should reject any subscriptions from unknown users or devices (opposite to the current recommendation)

- "If the profile delivery server does not accept the subscription from
   an unknown user or device, the administer or user must manually
   provoke the user agent to reSUBSCRIBE."

So what? a UA can automatically and regularly retry the subscription if it wants.

Section 3.7
------------

- "A user agent can provide hotelling by collecting a userËs AOR and
   credentials needed to SUBSCRIBE and retrieve the user's profiles.
   hotelling functionality is achieved by subscribing to the user's AOR
   and specifying the "user" profile type.  This same mechanism can also
   be used to secure a user agent, requiring a user to login to enable
   functionality beyond the default userËs restricted functionality."

Again, the user's AOR should not be explicitly required by the server. After authentication, the server should be able to deduce the user's AoR from some DB.

Section 3.8
------------

- Need more text in this section talking about app-id, event header etc.

Section 3.13.1
--------------

- What if instance does not matter? Example all Nokia phone 6600 model require the same profile, instance does not matter. Vendor and model is the only thing needed to download a profile. There is no need for the service provider to have separate profiles for every device, especially will they are identical.

Section 3.13.3
--------------

- about placing an "anonymous" user name. Why isn't sip:example.com enough (no user part)? If user part is present, it MUST be ignored.

Section 4.1.2
-------------

- I don't think this section should have normative text (SHOULD and MUST)

- "Once a user agent has successfully discovered, enrolled, received a
   NOTIFY response with profile data or URI(s), the user agent SHOULD
   cache the device profile SUBCRIBE URI to avoid having to rediscover
   the profile delivery server again in the future."

Why a SHOULD? the device profile SUBSCRIBE URI might be provided in the local profile, so SHOULD is only in certain circumstances that the URI was not in the local profile.

Section 4.1.3
--------------

- User's AoR can also be on the SIM card, for mobile devices with SIM cards.

Section 4.2
------------

- "However the profile server SHOULD
   accept (with 2xx response) SUBSCRIBE requests from any user agent as
   explained in Section 3.5."

I repeat my concerns here. This is a potential DoS attack.

Section 4.3
------------

- "Optionally the differential changes may be obtained by
   including the content-type defined in [I-D.ietf-simple-xcap-package]
   in the Accept header of the SUBSCRIBE request"

Which one? there are more than 1 MIME types defined in that draft.

Section 4.6
------------

- "This provides a convenient way for a single subscription to be used
   to obtain all application data.  The XCAP root is determined by a
   local mapping."

How? What does a NOTIFY body look like? This question also applies to the example later in the section:

"  SUBSCRIBE sip:[email-masked] SIP/2.0
   Event: sip-profile;profile-name=application

   The server would map the request URI to an XUI (user-aor, for
   example) and the xcap root based on local policy.  If there are two
   AUIDs, "resource-lists" [I-D.ietf-simple-xcap-list-usage] and
   "rls-services" [I-D.ietf-simple-xcap-list-usage], this would result
   in a subscription to all documents"

- This sentence:
   "When the
   "profile-name" is application, but the "app-id" parameter is absent,
   this specifies that the user wishes to SUBSCRIBE to all documents for
   all application usages associated with the user in the request-uri."

contradicts with this one:

"If the "profile-name"
   is "application", the "app-id" MUST be present as well."

The latter says its a MUST, but the former said the "app-id" missing is feature.

==================================================================================================
NITs
====

Section 2.3
------------

- s/ event packet/ event package
- s/ This make this/ This makes this
- s/ It is he author's/ It is the author's

Section 3.5
------------

- FTP reference missing

Section 3.7
------------

- 2x s/ userËs/ user's

Section 3.12
-------------

- SIP messages are not valid. For example, Via header is missing 

Section 3.13.1
---------------

- s/ loose/ lose

Section 3.13.3
--------------

- s/ the use part/ the user part

Section 4.1
------------

- s/ discover/ discovery

Section 4.1
------------

- a/ SUBCRIBE/ SUBSCRIBE

Section 4.2
-----------

- s/ discovery/ discover

Section 4.6
------------

- quotes are missing around the word "application". 3rd line, 3rd paragraph.
- "the server would the "device" profile ..." ???

_______________________________________________
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: Volker Hilt <[email-masked]>
Date: Wed, 29 Sep 2004 12:27:41 -0400

[email-masked] wrote:
> I don't believe this is needed. Authentication should be out of scope
> of this document. Also, the identity (AOR) of the user should be derived
 > after authentication locally, no need for the network-user param.
>
The URI of the SUBSCRIBE request for "local" profiles will point to the 
local network domain (e.g. [email-masked]) and it will therefore 
not contain the AoR of the user. Without the network-user parameter, the 
local network would not know the AoR of the subscribing user unless, of 
course, it derive the AoR through an authentication mechanism. With the 
"network-user" parameter the local profile type works with *and* without 
authentication.

> Again, the user's AOR should not be explicitly required by the 
> server. After authentication, the server should be able to deduce the
> user's AoR from some DB.
> 
Yes, authentication could provide the server with this information. But 
this would make authentication mandatory if the server wants to know the 
AoR. Not sure if we want to go down this path.

Thanks,

Volker