Subject: [Sipping] config-framework

From: Cullen Jennings <[email-masked]>
Date: Fri, 05 Nov 2004 17:05:05 -0800

I like how this is going and it is looking like it is getting close.

How the security works with content indirection confuses me. Say that the
scheme is HTTPS - how do I get a username password to the phone that is uses
for the HTTPS. How do I protect that. The odds that device has a cert that
the HTTPS server can use seems very low to me - at best it would indicate
hostname and that is not going to be useful in requesting a user profile
information such as buddy list.

I think we need to say that HTTP and HTTPS are must implement schemes for
content indirection if it is implemented.

Seems to have some bad characters in it.

Should vendor names be arbitrary self assigned strings or should they be a
domain that the vendors controls java style: ie "cisco" or "com.cisco"

Not sure I see why we need both document and app-id - I may be very confused
here

might need to describe hotelling where it is first used

On the topic of device URI, I tend to be on the path these days that UUID
should be strongly recommended.

Section 4.4 - tilt nit but the say this is written the SHOULD makes it
unclear if any MUST in section 6 is actual a SHOULD. I think should should
move the should to be just non normative here so that the normative language
in other sections is clear what it means.

split references to normative non normative

idnits says...
  Warnings:
    Line 507 has weird spacing: '...ication  of pr...'
    Line 871 has weird spacing: '...hat the  admin...'
    Line 1337 has weird spacing: '...Changes  in XM...'

_______________________________________________
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: "Daniel G. Petrie" <[email-masked]>
Date: Fri, 5 Nov 2004 18:58:17 -0800 (PST)

Cullen:
Thanks for the comments.  Response inline:

Cheers,
Dan

> to the phone that is uses

I only see two choices here:  Either the UA has
a cert. and the server validates it against the
identity somehow;  Or a RFC 2617 basic/digest based
password gets put on the UA through some out of band
means (e.g. typed in by user, SIM, bluetooth, etc.)

> for the HTTPS. How do I protect that. The odds that

"That" meaning protect the password stored on the user
agent? That sounds like an implementation problem of
how to safely store the password on the UA not an IETF
problem.

> device has a cert that

I agree RFC 2617 based authentication seems like a 
more likely and simpler solution.

> content indirection if it is implemented.

Ok.  I have added this to the sections 3.5 and 3.8 for
the next draft version

> Not sure I see why we need both document and app-id

I may be as well, but I will attempt to explain.
The document parameter may contain a relative path.
It the first path segment can be either global or
a user specific id.  If that is as far as the path
is specified, app-id may be used to further constrain
what profile data is desired.

> might need to describe hotelling where it is first

Added definitions for roaming and hotelling to section
2.2

> should be strongly recommended.

I still do not understand why we care how the instance
id is generated any more than we care for call-id.
I think it is fine to make a recommendation, but
this is an implementation issue.

> in other sections is clear what it means.

Will do.

> split references to normative non normative

Will do.

>     Line 1337 has weird spacing: '...Changes  in

Thanks. Fixed the first two the second one is in
the xcap-package reference.