PEP Issues
This is a list of open issues in the latest PEP
spec. If you have a new issue then please
send me a mail!
Open Issues
-
Warning header if proxy acts on behalf of others?
-
If a proxy takes out or adds a PEP declaration or policy then it should also
add a warning saying that this is the case
-
This is an open issue
-
Versioning and relations between protocols and their URIs
-
How can protocols be related. This should be a section under practical
considerations
-
It is the hope that this can be done with a reference to the DAV work
-
Describe the no-garbage principle in PEP spec when using a PEP extension
of strength MUST in the response: If the agent doesn't understand it it should
treat it as "application/octetstream"
-
The 421 status code should be removed. Legacy from previous draft
-
We need to clarify that an important purpose of the for list
in an extension policy can be used to provide policies about third party
sites.
-
Should we use the "*" mode in the map attribute as the default? That is,
each extension instance declares its own prefix instead of the actual headers.
Closed Issues
-
Emphasize on methods and error codes equivalents in PEP and explain why it
is better:
-
The method name and the status code are crowded places that are not easy
to extend without a central registry
-
Each
PEP
extension can be equivalent of a method
-
Each
PEP-Info
can be the equivalent of a set of error codes
-
Binding Requests
-
The
PEP-
prefix means that this method has been extended
-
The
PEP
method is a new method: The binding mechanism in this
request is not sub-classing any of the methods defined in HTTP/1.1 but is
completely new.
-
Explain the difference between sub-classing methods and new methods in the
"Binding HTTP Request" section
-
Explain the sentence "PEP-aware applications MUST prior to processing a binding
HTTP request remove the "
PEP-
" prefix from the method name leaving
the rest of the HTTP request as is."
-
Ordering
-
Mappings made at different point in times in long-lived mappings are not
ordered. Make note in "Identifying the Source of a Mapping"
-
Mapping and unmapping
-
Unmapping can be implicit
-
Exact same remapping is OK - It does not have to cause an error
-
Proxy servers simply pass through end-to-end extensions with
PEP-
prefix or a PEP
method
-
If they act as ultimate recipients then they can't forward a PEP method request
-
How to do proxy extensions as repeated hop-by-hop.
-
It is much safer to let the extension define itself in such a way that it
must be repeated on a hop by hop basis.
-
Link to other metadata mechanisms - PICS NG in particular
-
We don't need more than a single metadata model!
-
Explain how complex transactions can be done using PEP
-
How to make multiple binding extensions within a single transaction
-
This should be a separate section in the Binding HTTP Requests
-
Security: Be careful with mappings and remappings through proxies.
-
If a proxy client makes a mapping and then goes away and the proxy starts
using the same mapping then there is a problem finding out where the mapping
came from. This tells me that it is very important that we have a unique
way to say where a binding comes from. This is actually a problem even for
mappings that only last for a single transaction as they may get mixed up
with longer lived ones.
-
This is a security issue and will get a bullet there.
-
It should be posible to use relative URIs as extension identifiers
Henrik Frystyk Nielsen,
@(#) $Id: Issues.html,v 1.7 1997/08/11 14:15:58 jigsaw Exp $