Subject: RE: [Sipping] Comments on config framework draft

From: "Daniel G. Petrie" <[email-masked]>
Date: Sat, 23 Oct 2004 05:10:47 -0400

Hisham:
Thank you for the good comments and edits.  I have worked most of these
into the draft.  Some of these were already spun off on different threads.
I have pulled a few issues out and will spin a thread for them.  There are
a few comments and questions for clarification below.

Thank you very much.

Cheers,
Dan

Hisham Khartabil wrote:
> 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.

Changed

> 
> - "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.

added
> 
> 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.

I agree and have added text.
> 
> - "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.

There was a thread on this and I think that Volker explained the need.

> 
> - "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.

The server cannot enforce this.  Thanks to John Elwell'c comments, I
have made this non-normative here and made this normative in
section 3.8 Subscriber processing of NOTIFY requests

> 
> - "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?

Yes the example did not get updated with the changes in the last draft.
The example should look like:

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

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

Sorry, I am not following this.  The AOR is needed by the user agent so
that it can set the URI for the SUBSCRIBE for the user profile.  This is
in the case where the user agent either does not have a default user or
someone other than the default user wishes to have their user profile
effective on the user agent.

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

I will add some more.

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

There is a thread on this.  I think the user agent cannot make the decision
as to whether an instance id is needed.  I think that it should always include
one.  The profiles will not be identical in the bootstrapping case.  Each
device profile will minimally differ by the default user properties.

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

Doesn't what you suggest require a change to the way location services
provided through proxies and redirect servers work.  A special user name
seems like a lower impact, easier to implement change.

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

Ok, I will change it to recommended, but implementation choice.  I worry
a little that if each implementation uses a slightly different order
or suvset of the discovery steps, you will end up with different
results with user agents from different vendors.

> 
> - "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.

If my UA discovered it's profile when I plugged in the first time in the
office and later I went to the airport, I would not want to trust the
local network to over ride the device profile.  I am ok with the local
network providing constraints and policy, but not with it setting
configuration of my UA device profile.  Every time the URI changes
there should probably be a confirmation of trust/identity of the
profile delivery server.  The confirmation may require user 
prompting which is bother some in the least if it is every time
my UA changes local network domains.

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

I will add this and a note on it being pre-provisioned as well.

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

I will fix this.

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

I am not sure what the question is here.  The local mapping is an implementation
and configuration issue for the XCAP server.  The NOTIFY data format is
out of scope for this draft.

> 
> "  SUBSCRIBE sip:user-aor at example.com 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.
> 

I will fix this.  I think that the MUST was meant to be if 
profile-name is application AND "document" is specified THEN
app-id MUST be specified, but I think even that statement is
incorrect.  I have to think this through a bit.

> 
> ==================================================================================================
> NITs
> ====

Fixed.  

> 
> 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: [email-masked]
Date: Thu, 28 Oct 2004 17:12:43 +0300

> -----Original Message-----
> From: ext Daniel G. Petrie [mailto:[email-masked]]
> Sent: 23.October.2004 12:11
> To: Khartabil Hisham (Nokia-TP-MSW/Helsinki); [email-masked]
> Subject: RE: [Sipping] Comments on config framework draft
> 
> 
> > Section 3.7
> > ------------
> > 
> > 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.
> 

I misunderstood this one. I thought the user has to supply its AOR to the server using some parameter in the event header. Just ignore.

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

Not really. A server should understand the context in which the subscription is being made and need to rely on username for anything. You are subscribing to the server afterall and the request-uri carries the resource you are subscribing to.

/Hisham