Hi,

      I am going through draft-ietf-simple-event-list-07 and have a query
on Section 7

Section 7.1 specifies that  "any RLS which uses SIP back-end  subscriptions
to acquire information about the resources in a  resource list MUST be able
to act as an authentication service as  defined in [7], provided that local
administrative policy allows them  to do so."

If a RLS does not act as an authentication service, the procedure described
in Section 7.2 should be followed stated as
"RLSes which are in a  different domain than the subscriber on whose behalf
they are  creating back-end susbcriptions SHOULD subscribe to the resources
using their own identity.  By doing so, the RLS will generally obtain  only
the resource information which is made publicly available."

The limitation of the above as stated is the fact that the RLS will have
access to  only the resource information which is made publicly available
and NOT the information that would otherwise have been available had the
RLS subscribed to to the resource using the watcher's identity.  Further,
the RLS could be authenticated by the presentity using the digest mechanism
and therefore needs to have this capability too.

I would therefore like to know the pitfalls of an RLS not acting as an
authentication service since the same is not configured (both when the
watcher belongs to the RLS domain and does not belong to the RLS domain)
and at the same time not send out back-end subscriptions with the RLS's
identity.

Thank you very much
Regards
Nisha

***********************  FSS-Unclassified   ***********************
"DISCLAIMER: This message is proprietary to Flextronics Software Systems
Limited (FSS) and is intended solely for the use of the
individual to whom it is addressed. It may contain  privileged or
confidential information and should not be circulated or used for
any purpose other than for what it is intended. If you have received this
message in  error, please notify the originator immediately.
If you are not the intended recipient, you are notified that you are
strictly  prohibited  from  using, copying, altering, or disclosing
the contents of this message.  FSS  accepts no  responsibility  for loss or
damage arising from the use of  the information transmitted
by this email including damage from virus."

_______________________________________________
Sip-implementors mailing list
[email protected]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Reply via email to