Subject: P1394> RE: p1212r WG Tokyo meeting

From: Dave James <[email-masked]>
Date: Tue, 31 Mar 1998 12:53:32 -0800

To:      1212r Working Group (and interested individuals)
From:    David V. James, 1212r Chair
Subject: Next p1212r meeting, in Japan

This a minor revision of the previous Email that was
distributed by our host for the next p1212r meeting:

  Host: Atsushi_Nakamura
  Location: Canon, Japan

Please contact our host (Atsushi-san) if you plan
to attend, so that he can better plan for meeting
space and refreshments.

This p1212r meeting is intended to provide a
convenient forum for information sharing between
groups with similar interests. This intent is to
allow  1212r members to better respond to
the needs of active 1394 developers.

****************  -Meeting Details-  ***************

  1212r meeting, Tokyo Japan
  Monday April 20/21 1998 (intended to end early on April 21)
   (the Monday after the 1394 TA Korea meeting)
  10:30(AM)-17:00(PM)
  Tokyo(Kawasaki), Japan

  Hosted by:
  Canon Inc. Kosugi-office
  53 Imai Kami-cho
  Nakahara-Ku, Kawasaki-shi
  Japan
          
  (directions to the meeting room will be
   available in the office lobby)

  10-15 minutes walk from Musashi-Kosugi Station
  of either JR Nanbu-line, or Tokyu Toyoko-line.    
  The attached map shows the way to the
  Canon office from Musashi-Kosugi station.
  Musashi-Kosugi station is about 30min.
  train ride from Shibuya.

-------------- HOTEL -------------------

This hotel is a 2 minute walk from Musashi-Kosugi Station.
There are many other hotels in the Tokyo area,
and the train system is quite efficient.

Hotel The Ellcy
1-403 Kosugi-cho, Nakahara-ku
Kawasaki-shi
tel: 044-733-1111
(2 min walk from Musashi-Kosugi station )

-------------- HOST -------------------

Atsushi Nakamura
BJ Technology Development 22,
Canon Inc.

53 Imai Kami-cho
Nakahara-Ku, Kawasaki-shi
postal no. 211

tel:+81-3-44-733-6111(ext.5593)
    +81-3-44-739-6634(direct)
fax:+81-3-44-739-6756
email(1):[email-masked]
email(2):[email-masked]

-------------- AGENDA TOPICS ---------------

The following items have been submitted for discussion
at this meeting. Other items are welcome, but can be
best understood if distributed through the reflector
before the meeting.

We will start the meeting with a short introduction to
the CSR Architecture:
  Current specification
  Defined additions (SDD, FDS, language localization)
  Possible additions (proxy's, async channels, messages)
  Related services: number registry services 
  
At the end of the introduction, we will review agenda
requests, including the following, an schedule the
remaining time accordingly.

** Atsushi Nakamura agenda topics **

ITEM-1:
Discussion and voting to freeze the following key values:

1) Key value 1A......FDS Instance_Count
2) Key value 1B......FDS Function_Set(Affinity) directory
3) Key value 19.......FDS Function Info directory

according to the definition discussed in January, and
documented in the FDS document 98-002r0.pdf.

ITEM-2:
In order to effectively utilize the FDS addition for 1394,
a function_class listing registry is necessary either
at 1212 level, or 1394(TA) level.
My understanding is this is unlikely to happen at 1212 level,
so I would like to suggest that this issue (about a
function_class registry) be brought up at the
1394TA architecture liason report, or the 1212
study group, and that the p1212r WG proposes that the
1394TA would be a registry point for a extendable
function_class listing for 1394.
(Of course, we would have to come up with a initial list.)

ITEM-3:
Review the usage of "currentspecID".
Is it (will it be?) the rule that a
current spec ID entry is required as the
first enrty(the smallest ROM address)
for every directory ?

**** Dr. David V. James (Chair) topics ******
          (if time permits...)

ITEM-4: Asynchronous Channels.
Recent presentations (in several forums) by the Chair
have attempted to address the issue of streaming asynchronous
data between source and destination nodes. The intent
is to provide an asynchronous equivalent for isoch
channels and CIP headers. Inputs will be sollicited,
no decisions will be made.

ITEM-5: Message Passing.
The current CSR Architecture defines MESSAGE_REQUEST
and MESSAGE_RESPONSE registers, for use as target
addresses of unsollicited request and response
messages respectively. To be useful, these need
to be uniquely labeled, and perhaps tagged with
source and sequence numbers. An overview of the
possibilities will be presented; inputs will
be sollicited; no decisions will be made.

******************************************************************
* Dr. David V. James            * Tel: (408) 955-6295            *
* Sony Research Laboratories    * Fax: (408) 955-5180            *
* LSI Systems Laboratory        * email: [email-masked] *
* 3300 Zanker Road, M/S SJ-3D3  *        [email-masked] (home)      *
* San Jose, CA 95134            *                                *
******************************************************************