Re: I-D submission "Requirements on TV Broadcast URIs"

Craig A. Finseth wrote:
> 
>         ...
>    o  The URI scheme must be compatible with solutions already adopted
>       in standardisation bodies such as ATSC, DVB, and DAVIC.
>         ...
> 
> I see no reason to include this point.  None of the ATSC, DVB, or
> DAVIC proposed schemes meet the other requirements.  Thus, requiring
> compatability with something that does not meet the requirements is
> confusing at best.

If we have contradicting requirements, we need to balance somehow.
I don't agree the solution is by just kicking out a requirement.

You could argue to remove requiring compatibility with the ATSC URI 
scheme, because it is a not yet approved scheme. On the contrary, 
my impression is that DASE and our efforts are pretty aligned, such 
that we can expect the same URI scheme will get defined. Is this correct
?
It would mean that this requirement gets fulfilled in this respect.

The purpose of this requirement is to acknowledge that there are
other bodies also defining URI schemes. Somehow, we need to align.
Ignoring is not the way achieving that.

It seems people are not aware that the DAVIC URI scheme is something
existing and approved. The scheme is being implemented in the world.
I don't think we can simply ignore that, at least when trying to get 
something uniform and standardized.



> 
>    o  The URI scheme should support relative referencing such that
>       a TV-program with all its associated resources can be referenced
>       against a common base, which is the TV Broadcast URI of that
>       aggregate.
> 
> I would put this in the category of "nice, but if it doesn't work out,
> not a big deal."

The use of "should" should imply that.
I will insert some text stating that.


> 
>    5. Exceptions in TV Broadcast URIs
> 
>    TV Broadcast differs from the conventional Internet in several ways.
>    The TV Broadcast URI scheme is affected by that in the following aspects:
> 
>    o  The host is not necessarily a server identifyable through an
>                                            identifiable
corrected. thanks.
>       IP-address. For instance, the 'host' is a transport stream.
> Well, the "host" is the _source_ of a transport stream...

This is about modeling.

I like to make clear that the usual Internet model of 
hosts, routers and subnets doesn't apply perfectly to
the TV Broadcast environment. 

Correct me if I am wrong, but I understand a host as 
a machine hosting the server or client transport application.

The part after the double slash in the URI refers the
naming authority. In usual Internet that is (mostly) the 
server host. In broadcast, the client does not interact with 
the machine at the uplink side, but interacts with the data 
as made available in the broadcast transport stream. In our 
proposals, we are thinking of using the Transport Stream ID 
to identify our resources.

When the broadcast client starts a truly interactive session,
i.e. the content he requests gets scheduled and transmitted
because of that request, then we return to the Internet model
where the naming authority will be a machine again.

I think this is a fundamental difference in the model 
and I like to make that explicit. I think my wording does 
do that, by associating 'host' with 'transport'. If you 
have a better wording, please suggest.

Btw. In case of multicast, one connects to a multicast address.
Which machine is the host of that address ?


>         ...
> 
> Craig

Warner.

Received on Wednesday, 18 November 1998 03:58:00 UTC