Subject: [Sipping] question on draft-ietf-simple-event-list-06

From: [email-masked]
Date: Tue, 28 Dec 2004 16:13:42 +0100

Hello all
I have a small question for my clarification on
draft-ietf-simple-event-list-06 / section 6: example / flow F9.
In the flow F9:  The Local RLS subscribes to the state of the other
non-local
        resource. Local RLS -> RLS in example.org
My question is on how RLS in example.org can apply policies such as
allowing / forbidding some users (watcher [email-masked] in this example)
to get presence information when the back-end subscription (i.e. flow F9)
does not contain the name of the target UAC (i.e. sip:[email-masked] in
this example). Shouldn't - considering that example.org is a trusted domain
- a P-Asserted-Id="adam Roach" <sip:[email-masked]> be added in following
sip message layout of flow F9?

   SUBSCRIBE sip:[email-masked] SIP/2.0
   Via: SIP/2.0/TCP pres.example.com;branch=z9hG4bKFSrAF8CZFL
   Max-Forwards: 70
   To: <sip:[email-masked]>
   From: <sip:pres.example.com>;tag=a12eztNf
   Call-ID: [email-masked]
   CSeq: 980774491 SUBSCRIBE
   Contact: <sip:pres.example.com>
P-Asserted-Id="adam Roach" <sip:[email-masked]>
   Event: presence
   Expires: 3600
   Supported: eventlist
   Accept: application/cpim-pidf+xml
   Accept: application/rlmi+xml
   Accept: multipart/related
   Accept: multipart/signed
   Accept: application/pkcs7-mime
   Content-Length: 0

Best regards
L. Thiébaut

_______________________________________________
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: Adam Roach <[email-masked]>
Date: Tue, 28 Dec 2004 14:56:14 -0600

>sip message layout of flow F9?

P-Asserted-Id is only applicable in very limited circumstances, and 
certainly not the internet at large. It has no place in the discussion 
of a general purpose mechanism such as event lists.

Draft-ietf-simple-event-list-06 actually does define a mechanism to 
allow policy decisions, but I'm not going to describe it here, since 
that approach has been abandoned.

At the recent meeting in Washington, D.C., the working group reached 
consensus on a different approach for subscriber identity, using the 
mechanism defined by draft-ietf-sip-identity-03. I submitted a new 
version of the document on the 15th, but it has yet to appear in the 
document repository; see:

http://www.nostrum.com/~adam/ids/draft-ietf-simple-event-list-07.txt

In particular, section 7.1 and its subsections describe 
inter-presence-server authentication issues.

/a