Re: url clarification

[Martin Bjorklund <mbj@tail-f.com>]

Andy Bierman <ietf@andybierman.com> wrote:
> Did we ever resolve all the issues here? (A: no)
> 
> Here are the operations that use rpcOperationTargetType:
> 
>   operation            text-allows-url     notes
>   ------------------------------------------------
>   edit-config                N               1
>   copy-config                Y               2
>   delete-config              Y               3
>   lock                       N               4
>   unlock                     N               4

[...]

> Summary Issues:
> 
> A) Which is right: The text or the XSD?
>    Should the edit-config, lock, and unlock XSD definitions change from
>    rpcOperationTargetType to configNameType?  This will explicitly
>    disallow URL as <target> in these operations.

I think the text makes more sense than the XSD.


> B) If an agent advertises the :url capability, what operations
>    MUST, SHOULD, or MAY it apply to?  What if an agent only
>    supports URLs as the <source> parameter and not the <target> parameter
>    on some or all operations?

One example is the http/https schemes as target to copy-config.  Which
HTTP operation should the agent use?  PUT?  POST?


Another thing which is not clear is what the file pointed to by an url
looks like.  Suppose you send the agent the following command:

   <copy-config>
     <target>
       <url>ftp://ftp.server.com/my.conf</url>
     </target>
     <source>
       <config>
         <foo xmlns="http://my-foo-ns";>
           ...
         </foo>
         <bar xmlns="http"//my-bar-ns">
           ...
         </bar>
       </config>
     </source>
    </copy-config>

What will the 'my.conf' file look like?  Like this:

       <config>
         <foo xmlns="http://my-foo-ns";>
           ...
         </foo>
         <bar xmlns="http"//my-bar-ns">
           ...
         </bar>
       </config>

This would be a valid XML document, where 'config' does not belong to
any namespace.  Another alternative is the same contents but w/o the
<config> element, but that wouldn't be valid XML.  There are some
other reasonable alterantives as well.  Maybe this also is
implementation-specific?  (with the usual inter-op drawbacks)



/martin








--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>