[Simple] RE:I-D ACTION:draft-ietf-simple-partial-pidf-format-08.txt

["Konka Ravinder-rnbk38" <[e-mail]>]

These are my open comments which comes to view when I was going thru the partial-pidf!!! Just an insight!!!.
May be we could handle partial pidf in a different perspective?.

1. We could have a mechanism where the published pidf whether it is partial or full, pidf needs to be updated/ modified with elements present in the pidf published recently with keeping other elements in older pidf intact.
2. This avoids the overhead at network side as well as at terminal/ua side.
3. And also if 'application/pidf-diff+xml' MIME type is introduced, then this may lead to problems in real time scenarios, 
Where user tries to publish pidf-diff, but there was no pidf-full already exist, or else pidf exist but the specific entities/elements are doesn't exist in pidf.
4. Best way to publish the content of a presentity is keeping the MIME type 'application/pidf+xml' intact, and follow the procedure in step 1, outlined above.
 

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] 
Sent: Tuesday, November 21, 2006 12:37 PM
To: [e-mail]
Subject: Simple Digest, Vol 31, Issue 4

Send Simple mailing list submissions to
	[e-mail]

To subscribe or unsubscribe via the World Wide Web, visit
	https://www1.ietf.org/mailman/listinfo/simple
or, via email, send a message with subject or body 'help' to
	[e-mail]

You can reach the person managing the list at
	[e-mail]

When replying, please edit your Subject line so it is more specific than "Re: Contents of Simple digest..."


Today's Topics:

   1. Re: What is the proper winfo status when watcher is politely
      blocked (Jonathan Rosenberg)
   2. Comments on presence-rules-08 (Vrancken, Johnny)
   3. I-D ACTION:draft-ietf-simple-partial-pidf-format-08.txt 
      ([e-mail])
   4. draft-ietf-simple-presence-rules-08.txt - XCAP naming
      conventions (Vaclav Kubart)
   5. Re: Belated review of draft-urpalainen-simple-xcap-webdav
      (Jari Urpalainen)


----------------------------------------------------------------------

Message: 1
Date: Wed, 08 Nov 2006 13:14:30 -0500
From: Jonathan Rosenberg <[e-mail]>
Subject: Re: [Simple] What is the proper winfo status when watcher is
	politely	blocked
To: [e-mail]
Cc: [e-mail]
Message-ID: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed

Its "active". The winfo state machine doesnt reflect the nuances of document filtering and manipulation, only the state of the presence subscription.

-Jonathan R.

[e-mail] wrote:

> Hello all,
> 
> I have encountered an issue with the watcher info. I can't find a clue in solvin this situation.
> 
> 1. User A sets "polite-block" authorization policy on user B 2. User A 
> subscribes own watcher info 3. User B subscribes user's A presence -> 
> gets polite document 4. User A receives winfo notification - now I 
> dont know what shall be the proper value for "status" attribute?
> 
> Any help is really appreciated.
> 
> 
> br, Martin
> 
> _______________________________________________
> Simple mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/simple
> 

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[e-mail]                              FAX:   [phone]
http://www.jdrosen.net                         PHONE: [phone]
http://www.cisco.com



------------------------------

Message: 2
Date: Mon, 13 Nov 2006 10:38:58 +0100
From: "Vrancken, Johnny" <[e-mail]>
Subject: [Simple] Comments on presence-rules-08
To: "Jonathan Rosenberg" <[e-mail]>
Cc: [e-mail]
Message-ID:
	<[e-mail]>
Content-Type: text/plain; charset="iso-8859-1"

Dear Jonathan,

Here are a few  comments / questions on draft-ietf-simple-presence-rules-08.txt:

§3.2.1 Subscription Handling, page 8
In order to align with the terminology used in RFC 3857 / Figure 1 and RFC 3858, the following changes are recommended:
for block: subscriptions are placed in the "terminated" state (authorization policy / decision ="reject") for polite-block & allow: subscriptions are placed in the "active" state (authorization policy / decision ="accept")

§3.2.1 Subscription Handling, page 9, last paragraph:
"If the sub-handling permission changes value to "polite-block" or "allow", this causes an "approved" event to be generated into the state machine for all affected subscriptions. "
This is not completely true. If e.g. the sub-handling permission changes from "allow" to "polite-block", or from "polite-block" to "allow", the subscription is and remains in the "active" state and no event is generated.
So if the sub-handling permission changes value to "polite-block" or "allow", the processing depends on the state of the affected subscriptions. Only if the subscription is in the "pending" state, the subscription state changes and a NOTIFY is sent. There is no change in state if the subscription is in the active, waiting or terminated state.

§3.3 Transformations
Considering the statements in §3.3.1 and §3.3.2, you need both a fine gained access permission (§3.3.2) and a corresponding coarse grained access permission (§3.3.1)to grant access to presence attributes.
So the most compact form of granting access of all presence attributes to all watchers is the following rule:
<rule id="GrantAll" >
  <actions> <sub-handling>allow</sub-handling> </actions>
  <transformations>
    <provide-persons> <all-persons/> </provide-persons>
    <provide-services> <all-services/> </provide-services>
    <provide-devices> <all-devices/> </provide-devices>
    <provide-all-attributes/>
  </transformations>
</rule>

Question: is it a correct statement that a "false" valued boolean permission serves no purpose unless combined with a <provide-all-attributes/> permission ?
I.e. the following rule without a <provide-persons> or <provide-all-attributes> statement doesn't grant anything.
<rule id="GrantAllPersonsExceptMood" >
  <actions> <sub-handling>allow</sub-handling> </actions>
  <transformations>
    <provide-persons> <all-persons/> </provide-persons>
    <provide-all-attributes/>
    <provide-mood> false </provide-mood>
  </transformations>
</rule>

Question: is the following transformation in a single matching rule <transformations>
    <provide-persons> <all-persons/> </provide-persons>
    <provide-status-icon> true </provide-status-icon>  </transformations>

semantically equivalent to the following 2 transformations in 2 matching rules, or are these 2 transformations meaningless ?
In Rule 1: <transformations>
    <provide-persons> <all-persons/> </provide-persons> </transformations> In Rule 2: <transformations>
    <provide-status-icon> true </provide-status-icon> </transformations>

===========
NITS:
Page 8: ... Strictly speaking, it is not necessary to every RULESET TO include an explicit block action Page 9: ... and the value of sub-handling that APPLIES to that subscription is "CONFIRM", ... ("pending" to be replaced by "confirm" ) Page 17: ... that used <provide-unknown-attribute> VALUED "TRUE" for some attribute, say foo.
Page  18: ... will be granted access to THE PRESENCE DATA OF all services whose contact URI ....

Kind regards,
Johnny



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www1.ietf.org/pipermail/simple/attachments/20061113/dc8c49d3/attachment-0001.html

------------------------------

Message: 3
Date: Wed, 15 Nov 2006 15:50:01 -0500
From: [e-mail]
Subject: [Simple] I-D
	ACTION:draft-ietf-simple-partial-pidf-format-08.txt
To: [e-mail]
Cc: [e-mail]
Message-ID: <[e-mail]>
Content-Type: text/plain; charset="us-ascii"

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF.

	Title		: Presence Information Data format (PIDF) Extension for Partial Presence
	Author(s)	: M. Lonnfors, et al.
	Filename	: draft-ietf-simple-partial-pidf-format-08.txt
	Pages		: 17
	Date		: 2006-11-15
	
The Presence Information Document Format (PIDF) specifies the
   baseline XML based format for describing presence information.  One
   of the characteristic of the PIDF is that the document always needs
   to carry all presence information available for the presentity.  In
   some environments where low bandwidth and high latency links can
   exist it is often beneficial to limit the amount of transported
   information over the network.  This document introduces a new MIME
   type which enables transporting of either only the changed parts or
   the full PIDF based presence information.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-simple-partial-pidf-format-08.txt

To remove yourself from the I-D Announcement list, send a message to [e-mail] with the word unsubscribe in the body of the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-simple-partial-pidf-format-08.txt".

A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-simple-partial-pidf-format-08.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft.
-------------- next part --------------
Skipped content of type multipart/alternative

------------------------------

Message: 4
Date: Mon, 20 Nov 2006 17:40:32 +0100
From: Vaclav Kubart <[e-mail]>
Subject: [Simple] draft-ietf-simple-presence-rules-08.txt - XCAP
	naming	conventions
To: [e-mail]
Message-ID: <[e-mail]>
Content-Type: text/plain; charset=us-ascii

Hi all,
I'm trying to implement presence server and I encountered a problem how to get authorization rules for specific user from XCAP server. In section 8.7 Naming Conventions is:

   'When a presence agent receives a subscription for some user foo
   within a domain, it will look for all documents within http://[xcap
   root]/pres-rules/users/foo, and use all documents found beneath that
   point to guide authorization policy.  If only a single document is
   used, it SHOULD be called "index".'

But as far as I know there is no possibility to list documents for a user in XCAP server...

Missed I something? Or should be the file "index" in user's directory used to union all other user's files?

	thanks for your advices,

		Vaclav




------------------------------

Message: 5
Date: Tue, 21 Nov 2006 09:06:31 +0200
From: Jari Urpalainen <[e-mail]>
Subject: [Simple] Re: Belated review of
	draft-urpalainen-simple-xcap-webdav
To: ext Lisa Dusseault <[e-mail]>
Cc: [e-mail], [e-mail]
Message-ID: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Thanks Lisa for your comments, more inline. And sorry for cross-posting but this might interest both groups.

ext Lisa Dusseault wrote:
>
> Hi Jari,
>
> I finally got around to reviewing this draft, version -01.  The basic 
> model I completely agree with, it's the easiest one and quite useful.
great.
>
> Some comments:
>
>     - Is it necessary to say that the ETag used with XCAP operations 
> is the exact same as the one used in WebDAV operations?  This allows a 
> client to use both XCAP and WebDAV without repeating ETag queries or 
> worrying about keeping two sets of ETags.  This may be obvious already 
> since both WebDAV and XCAP only use HTTP ETags.
imo, (and being an implementer) yes they must not be separate. And even implementation on top of Apache is simple (though it does response with weak ETags, but it is easy to patch it once you do have source code ;-) )
>
>     - Section 4.6: I'm not 100% sure that existing software out there 
> will all work with a WebDAV Principals namespace of the form 
> "http://principals.example.com/".  More typically you see principal 
> namespaces inside the same domain name as the server that hosts the 
> content.  So you might see "http://example.com/principals" or 
> "http://example.com/servlet/acl/principals".  I do not know if these 
> forms have any disadvantages over the form you suggest but in ACL 
> deployment so far they're more likely to be seen.  I agree that 
> principal namespaces on different domains is probably OK, but we might 
> want to think for a moment about whether it would be OK for a server 
> with content at "example.com" could have its principals at a 
> completely different DNS tree, e.g. "identities.example.ru".
ok, I just not wanted to mess up with xcap conventions, i.e. principal entities would not interfere with an xcap application usage.  If <http://example.com/principals> is better inline with current deployments I'm fine with that as well (virtual hosting is easy imo and/or reverse proxy configurations do help here anyway). Anyhow, this is only a recommendation and just to try to help the provisioning nightmare... And of course this should be (or have been) in rfc3744, imo, i.e. some conventions, though not being mandatory are typically useful for implementations.
>
>     - You might want to add that the location for principals can be 
> discovered by doing an OPTIONS request and asking for the principals 
> namespace.  Is there an alternative (XCAP) way of discovering the 
> location?
>
XCAP hasn't anything for this (just capability au). Are you proposing adding some mime type for OPTIONS * ?  Certainly it would help provisioning...
>     - In section 4.6, you say "The user "joe" is thus an XCAP user 
> identity (XUI)".  This is descriptive, not normative.  Would it be 
> better to turn this into a normative requirement?  E.g.
>     "A server that implements both WebDAV and XCAP MUST support the 
> same principal namespace for both WebDAV ACL usage and XCAP user 
> identities (XUI).  That is, every valid WebDAV principal MUST also be 
> a XUI, and vice versa."
right, I agree.
>
>     - You might add a property to a principal, such that an 
> application that knows "who am I" (it has discovered its principal 
> identity as currently authenticated) can discover where its XCAP 
> application "home directories" are.  For example, this could be a 
> multi-valued property valid on a Principal Resource, e.g.
>     <DAV:prop>
>         <XCAP:xcap-home-directories xmlns:XCAP="some XCAP namespace">
>             
> <DAV:href>http://example.com/com.example.anAUID/joe/</DAV:href>
>             <DAV:href>http://example.com/resource-lists/joe/</DAV:href>
>         </XCAP:xcap-home-directories>
>     </DAV:prop>
>
>     Even more generally, this property could identify the user's XCAP 
> documents of all kinds directly.
right, again sounds reasonable to have xcap home directory principal property, the xcap capability extension lists available AUs. This seems to add some content to this i-d, btw ;-).
>
>     - You might want to note that XCAP applications can add their own 
> privileges to the set of base WebDAV privileges.  For example, let's 
> say we had an XCAP application defined for conferencing.  Part of the 
> conference application has conference room setup -- what server it's 
> on, what bandwidth reserved.  But another part of the conference 
> application is for moderation: who can provide input without 
> moderation, who is on the "moderate their input" lists, and who is 
> entirely blocked.  For this application, we might want to define a 
> special XCAP conferencing "moderator" privilege that could do some set 
> of functions but not as much as the administrator who can edit the 
> entire XCAP document.  The XCAP server would of course apply the 
> custom privilege and would allow or disallow PUT and DELETE to XCAP 
> node selector URLs, based on the privilege and the principal.
>     <DAV:grant>
>         <DAV:privilege><XCON:moderate xmlns:XCON="Some conferencing 
> namespace"/>
>         </DAV:privilege>
>     </DAV:grant>
>
right. rfc3744 is extensible (and the basic model/idea is very reasonable, imo).
>     - Section 5, error handling:  Since this document says that a 
> client is not to send WebDAV requests to XML node selector URLs, I 
> think the best response to seeing such a request would be in the 
> 400-series -- possibly 403 Forbidden.  To make it clear what exactly 
> is forbidden, you can define an XML error code for return in the error 
> body, e.g.
>     <DAV:error>
>         <xcap:webdav-request-to-node-selector/>
>     </DAV:error>
>
agreed, some deterministic (and documented) responses are definitely better.
>
> You can send these comments to a WG or discussion list if you like.
> Thanks,
> Lisa
>
Thank you,
Jari



------------------------------

_______________________________________________
Simple mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/simple


End of Simple Digest, Vol 31, Issue 4
*************************************

_______________________________________________
Simple mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/simple