OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: Re: [wsrp] [wsrp-wsia joint interfaces] Call in numbers fortelecon,Tuesda y 9 April




Michael, Alan,

see some comments on the privacy and firewall topic below ...

Best regards,

Thomas


Michael Freedman <Michael.Freedman@oracle.com> on 04/09/2002 12:13:53 AM

Please respond to Michael Freedman <Michael.Freedman@oracle.com>

To:    Alan Kropp <akropp@epicentric.com>
cc:    "'wsrp@lists.oasis-open.org'" <wsrp@lists.oasis-open.org>,
       "'wsia@lists.oasis-open.org'" <wsia@lists.oasis-open.org>
Subject:    Re: [wsrp] [wsrp-wsia joint interfaces] Call in numbers for
       telecon,Tuesda   y 9 April



Alan,
    I have read through the 2 Use Case Reports: Embedded Producers and
    Customized
Producers.  As tomorrow's discussion is focused on the Embedded case most
of my
questions pertain to it.  However I do have a general question -- I was
surprised
that "Customized Producer" document reinvented alot of what was in the
Embedded
Producers document -- By reinvented I mean tackled alot of the same
function though
at times a little differently (What's all this stuff about stream oriented
operations anyway?).  Am I correct that the "Customized" case is merely the
"Embedded" case plus the ability of the consumer to allow a producer to
expose and
manage instance settings?  Can you clarify?
    As for the embedded case, I need some help with terminology.   What are
properties?  Are they "producer meta data"?  Are they arbitrary request
parameters?  both?  What are WSIA portTypes?


    And then specifically on the document:

Section 1: Producers do not publish an interface to the consumer other than
for
invocation with generic arguments.  What does this mean?  Why is this
defined?

Section 3.1.1: URL rewriting:  Note: <img> tags may also need to be
rewritten -- If
the portlet lives behind a firewall the only way for a client to
communicate to it
may be via the portal even to get basic things like images.

<ts>
Do you mean the scenario where a corporation has set up a firewall that
allows
employees only to go to "allowed" sites, including a portal that in turn
acts as a
gateway to selected content from the Internet and therefore there's no
direct access
to the server providing the interactive portlet sevice ? Or a scenario
where the
WSRP service would be behind a firewall ?


From a portlet service perspective, I would expect that a public
user-facing,
interactive service would be complemented by a public HTTP server that
would serve up
an static content referenced from markup generated by the service.
</ts>


Section 3.1.1: User profile:  What discussions are you having about
privacy?  How
does the consumer know whether the end user wants the producer to have
access to
its profile information?  Or is there a basic set of profile information
that users
give up their privacy rights over?

<ts>This seems something to be left to be decided by the portal servers -
in the
portal servers, there might be UIs that let users or administrators on
behalf of
users decide which user attributes may be sent to which remote services

The P3P approach is basically that users are at all times informed about
what data
is used how and that they may define their privacy preferences to be
enforced by
the user agent - which in the WSRP case would be the portal.
</ts>

Section 3.1.1: Operations/Actions:  What are operations/actions?  Why do
they
exist?  Are there consumer defined actions producers must be aware of?

Section 7.1: Lifecyle -- "We therefore introduce the concept of a 'Handle'
as a
remote opaque reference to an instance of the service -- this reference may
be
equivalent to session data.".  Can you clarify what handle this is?  Is it
a
persistent handle?  Or merely a runtime handle?  Given that "Embedded"
doesn't
define customizations it would seem to be the later.

Section 7.2.1: URL rewriting:  there is a need to insert an additional
parameter
(wsai:mapKey).  Why? The document references a consumer maintained mapping
table
but doesn't motivate such a thing -- what specifically is this mapping
table used
for and why is it needed?  Even if its needed, why doesn't the consumer
generate
its own mapKey as its doing the substitution?

Section 7.4.4:  Are you planning on defining names or types to represent
markup
fragment rules?  I.e. I can conceive of two different consumers having two
different sets of markup rules (one consumer embeds you in an HTML table
while
another uses frames).  In such a world don't the consumer/producer need to
determine if they are compatible by discovering each others capabilities?

Section 7.6.4: A producer must specify its supported properties.  Why?  or
at least
Why all of them?  This goes back to my initial questions concerning what
properties
are.  I understand why you would specify what WSIA properties you support
but its
not clear why anything else.

Section 7.7: Output -- Thomas raised the question/need that a producer may
generate
output that has to be aggregated into different locations in the markup.
Is this
something that should be covered/identified here?

      -Mike-



Alan Kropp wrote:

> These call-in numbers are permanent going forward.
>
>  USA Toll Free Number: 877-718-0936
>  USA Toll Number: +1-712-923-6878
>   PARTICIPANT PASSCODE: 563151
>
> This week's agenda is to walk through the Embedded use case in detail,
and
> pay particular attention to the interface points with WSRP, especially as
> details are emerging about WSRP requirements in the following areas:
>
> 1.  Property setting
> 2.  URL rewriting
> 3.  Lifecycle management
> 4.  Security/privacy/authentication
>
> The current draft is enclosed.
>
> Alan
>
> -----Original Message-----
> From: Alan Kropp [mailto:akropp@epicentric.com]
> Sent: Friday, March 29, 2002 10:24 AM
> To: 'wsrp@lists.oasis-open.org'; 'wsia@lists.oasis-open.org'
> Subject: [wsrp][wsia] Call in numbers for joint interface telecon,
> Tuesday 2 April
>
> Below please find the information for Tuesday's joint interface group
> telecon.  If you're calling from outside the US, could you please send me
an
> email..I'll need a count of international callers in case I need to
increase
> the number of slots.
>
> Thank you.
>
>  CALL DATE:         APR-02-2002  (Tuesday)
>  CALL TIME:         09:00 AM PACIFIC TIME (12:00 Eastern)
>  DURATION:              1 hr
>  USA Toll Free Number: 888-677-5736
>  USA Toll Number: +1-630-395-0182
>   PASSCODE: 29067
>   LEADER:            Mr Alan Kropp
>
> Alan Kropp
> Epicentric, Inc.
> akropp@epicentric.com
> 415 995-3512 direct
> 415 974-9821 fax
> http://www.epicentric.com
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
>
>
------------------------------------------------------------------------
>                                         Name: WSIA Embedded Use Case.DOC
>    WSIA Embedded Use Case.DOC           Type: WINWORD File
(application/msword)
>                                     Encoding: BASE64
>                              Download Status: Not downloaded with message


----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>





[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC