Subject: Re: [siprec] siprec Digest, Vol 3, Issue 50

From: zhipeng zhou <[email-masked]>
Date: Mon, 24 May 2010 11:01:02 +0800

Hi all,
A question on the response for #16:

We can see that the charter has specified the scope as follows:
"
 The scope of the activity includes:

  * Recorder Control

  * Session metadata content and format

  * Security mechanisms, including transport and media encryption

  * Privacy concerns, including end-user notification

  * Negotiation of recording media streams

".
As for recording applicaion and the transcoding functionality, I do feel we
do not need to specify how to do the medeia transcoding (it is the scope of
codec), while how to fulfill the negotiation and control of the transcoding
appears obviously  a necessary part for the recording solution.
Given we should face the diversity of media types, may we consider a
recording system that does not support this requirement for media adjusting.

Thanks.
Zhipeng

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Sunday, May 23, 2010 3:00 AM
To: [email-masked]
Subject: siprec Digest, Vol 3, Issue 50

If you have received this digest without all the individual message
attachments you will need to update your digest options in your list
subscription.  To do so, go to 

https://www.ietf.org/mailman/listinfo/siprec

Click the 'Unsubscribe or edit options' button, log in, and set "Get MIME or
Plain Text Digests?" to MIME.  You can set this option globally for all the
list digests you receive at this point.

Send siprec mailing list submissions to
	[email-masked]

To subscribe or unsubscribe via the World Wide Web, visit
	https://www.ietf.org/mailman/listinfo/siprec
or, via email, send a message with subject or body 'help' to
	[email-masked]

You can reach the person managing the list at
	[email-masked]

When replying, please edit your Subject line so it is more specific than
"Re: Contents of siprec digest..."

Today's Topics:

   1. Re: #16: To support real-time media adjusting
      (siprec issue tracker)
   2. Re: #3: Mixed or separate media streams (siprec issue tracker)
   3. Re: #10: What is Meta-Data? (siprec issue tracker)
   4. Re: #10: What is Meta-Data? (siprec issue tracker)

----------------------------------------------------------------------

Message: 1
Date: Sat, 22 May 2010 05:49:43 -0000
From: "siprec issue tracker" <[email-masked]>
Subject: Re: [siprec] #16: To support real-time media adjusting
To: [email-masked]
Cc: [email-masked]
Message-ID: <[email-masked]>
Content-Type: text/plain; charset="utf-8"

#16: To support real-time media adjusting
--------------------------------+---------------------------------------
--------------------------------+----
 Reporter:  zhouzp@?            |        Owner:  krehor@?        
     Type:  enhancement         |       Status:  closed          
 Priority:  major               |    Milestone:                  
Component:  Requirements        |      Version:  1.0             
 Severity:  Active WG Document  |   Resolution:  wontfix         
 Keywords:  transcode           |  
--------------------------------+---------------------------------------
--------------------------------+----
Changes (by krehor@?):

  * status:  new => closed
  * resolution:  => wontfix

Comment:

 While we agree this can be an important use case, media transcoding is out
of scope for this working group's charter.

--
Ticket URL: <http://trac.tools.ietf.org/wg/siprec/trac/ticket/16#comment:1>
siprec <http://tools.ietf.org/siprec/>

------------------------------

Message: 2
Date: Sat, 22 May 2010 06:00:44 -0000
From: "siprec issue tracker" <[email-masked]>
Subject: Re: [siprec] #3: Mixed or separate media streams
To: [email-masked], [email-masked],
	[email-masked]
Cc: [email-masked]
Message-ID: <[email-masked]>
Content-Type: text/plain; charset="utf-8"

#3: Mixed or separate media streams
------------------------------------------------+---------------------------
 Reporter:  john.elwell@?                       |        Owner:  krehor@?

     Type:  defect                              |       Status:  closed

 Priority:  major                               |    Milestone:  milestone1

Component:  Requirements                        |      Version:

 Severity:  Candidate WG Document               |   Resolution:  fixed

 Keywords:                                      |  
------------------------------------------------+---------------------------
Changes (by krehor@?):

  * status:  new => closed
  * resolution:  => fixed

Comment:

 REQ-012 covers the case of mixed audio, REQ-013 covers multiple media
 streams via multiple recording sessions, and REQ-014 covers the case of
 separate media streams.

 Ken

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/siprec/trac/ticket/3#comment:3>
siprec <http://tools.ietf.org/siprec/>

------------------------------

Message: 3
Date: Sat, 22 May 2010 06:03:52 -0000
From: "siprec issue tracker" <[email-masked]>
Subject: Re: [siprec] #10: What is Meta-Data?
To: [email-masked], [email-masked], [email-masked],
	[email-masked],	[email-masked]
Cc: [email-masked]
Message-ID: <[email-masked]>
Content-Type: text/plain; charset="utf-8"

#10: What is Meta-Data?
-----------------------------------+----------------------------------------
 Reporter:  deepanshu@?            |        Owner:  krehor@?        
     Type:  defect                 |       Status:  closed          
 Priority:  major                  |    Milestone:  milestone1      
Component:  Requirements           |      Version:                  
 Severity:  Candidate WG Document  |   Resolution:  fixed           
 Keywords:                         |  
-----------------------------------+----------------------------------------
Changes (by krehor@?):

  * status:  new => closed
  * resolution:  => fixed

Comment:

 Revised the definition of metadata to include both Communication Session
 and Recording Session.

 We plan to address the specifics of metadata (content, format, etc.) at a
 later date.

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/siprec/trac/ticket/10#comment:5>
siprec <http://tools.ietf.org/siprec/>

------------------------------

Message: 4
Date: Sat, 22 May 2010 07:26:38 -0000
From: "siprec issue tracker" <[email-masked]>
Subject: Re: [siprec] #10: What is Meta-Data?
To: [email-masked], [email-masked], [email-masked],
	[email-masked],	[email-masked]
Cc: [email-masked]
Message-ID: <[email-masked]>
Content-Type: text/plain; charset="utf-8"

#10: What is Meta-Data?
-----------------------------------+----------------------------------------
 Reporter:  deepanshu@?            |        Owner:  krehor@?        
     Type:  defect                 |       Status:  closed          
 Priority:  major                  |    Milestone:  milestone1      
Component:  Requirements           |      Version:                  
 Severity:  Candidate WG Document  |   Resolution:  fixed           
 Keywords:                         |  
-----------------------------------+----------------------------------------

Comment(by deepanshu@?):

 What is the revised text?

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/siprec/trac/ticket/10#comment:6>
siprec <http://tools.ietf.org/siprec/>

------------------------------

_______________________________________________
siprec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/siprec

End of siprec Digest, Vol 3, Issue 50
*************************************

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 24 May 2010 11:15:01 +0200

Zhipeng,

"Use Case xx: Recording with Real-time Media Adjusting
Recording applications require the recording server to issue appropriate media steams to be adapted to the client's media capability and the network bandwidth.
During the realtime media communication, either the media's tranport rate or the media types or the video framesize may be adjusted. 
To support the media adjustion, a transcoder entity is recommended."

I have difficulty understanding the use case. In particular, the text "the recording server to issue appropriate media steams" seems to suggest we are talking about playback, which is outside the scope of siprec. If this is not the right interpretation of this text, please explain the use case more clearly. Once we have established a clear use case and determined whether it will have impact on siprec, we can open a new issue if appropriate.

John (as chair)

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of zhipeng zhou
> Sent: 24 May 2010 04:01
> To: [email-masked]; [email-masked]
> Subject: Re: [siprec] siprec Digest, Vol 3, Issue 50
> 
>   Hi all,
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Ticket URL: 
> <http://trac.tools.ietf.org/wg/siprec/trac/ticket/16#comment:1>
> Ticket URL: 
> <http://trac.tools.ietf.org/wg/siprec/trac/ticket/3#comment:3>
> Ticket URL: 
> <http://trac.tools.ietf.org/wg/siprec/trac/ticket/10#comment:5>
> Ticket URL: 
> <http://trac.tools.ietf.org/wg/siprec/trac/ticket/10#comment:6>

---

From: zhipeng zhou <[email-masked]>
Date: Mon, 24 May 2010 17:52:53 +0800

Hi John,
nowadays there are many different types of medias, such as multiple
standards of voice coding and video coding.
Particularly some new industry solutions for the media communication (such
as flv) have been widely used and will appear continually.
So, for any multimedia solution it should be important to keep open for
multiple media types.
While, for clients, they always have different kind of terminals. So the
terminals have different capabilties for the media communication.For example
my mobile phone does not support flv. 
Hence, to negotiate a proper media type between server and client in the
application is very important.
For the bandwidth, it is very similar that on different communiation session
the bandwidth is different. For example some are based on 3G wireless and
some are based on  GPRS. So it should be required for the recording system
to support a wide rate range for multimedia communications. Of course, that
will permit different multimedia quality for the service.
Thanks.
Zhipeng

-----Original Message-----
From: Elwell, John [mailto:[email-masked]] 
Sent: Monday, May 24, 2010 5:15 PM
To: zhipeng zhou; [email-masked]; [email-masked]
Subject: RE: [siprec] siprec Digest, Vol 3, Issue 50

Zhipeng,

"Use Case xx: Recording with Real-time Media Adjusting Recording
applications require the recording server to issue appropriate media steams
to be adapted to the client's media capability and the network bandwidth.
During the realtime media communication, either the media's tranport rate or
the media types or the video framesize may be adjusted. 
To support the media adjustion, a transcoder entity is recommended."

I have difficulty understanding the use case. In particular, the text "the
recording server to issue appropriate media steams" seems to suggest we are
talking about playback, which is outside the scope of siprec. If this is not
the right interpretation of this text, please explain the use case more
clearly. Once we have established a clear use case and determined whether it
will have impact on siprec, we can open a new issue if appropriate.

John (as chair)

> As for recording applicaion and the transcoding functionality, I do 
> feel we do not need to specify how to do the medeia transcoding (it is 
> the scope of codec), while how to fulfill the negotiation and control 
> of the transcoding appears obviously  a necessary part for the 
> recording solution.
> [mailto:[email-masked]] On Behalf Of [email-masked]
> Click the 'Unsubscribe or edit options' button, log in, and set "Get 
> MIME or Plain Text Digests?" to MIME.  You can set this option 
> globally for all the list digests you receive at this point.
> 
> 
> 
>  While we agree this can be an important use case, media transcoding 
> is out of scope for this working group's charter.
> 
> --
> Ticket URL: 
> streams via multiple recording sessions, and REQ-014 covers the case 
> of  separate media streams.
> 
>  Ken
> 
> --
> Ticket URL: 
>  Revised the definition of metadata to include both Communication 
> Session  and Recording Session.
> 
>  We plan to address the specifics of metadata (content, format, etc.) 
> at a  later date.
> 
> --
> Ticket URL: 
> =

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 24 May 2010 12:15:50 +0200

Zhipeng,

The range of media formats and bandwidths that a SRS will support will be a matter of policy for a given deployment, and outside the scope of siprec. Clearly there has to be a mechanism for negotiating formats and bandwidths to be used, and I don't see a requirement addressing that at present. So would addition of a requirement along the lines of the following be sufficient to satisfy your concern?
"The mechanism MUST provide a means for the SRC and SRS to agree on media to be recorded and on formats and bandwidths for transporting those media to the SRS."

John (as individual)

> From: zhipeng zhou [mailto:[email-masked]] 
> Sent: 24 May 2010 10:53
> To: Elwell, John; [email-masked]; [email-masked]

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 24 May 2010 09:00:47 -0400

Why does the recording server need to transcode anything?
Can it not just record the bits as they are?

	THanks,
	Paul

---

From: zhipeng zhou <[email-masked]>
Date: Tue, 25 May 2010 14:12:00 +0800

Hi John,
Except your suggested additional requirement, we'd consider the features of
real time since it is closely related to the quality.
For example, if the big delay happens, the session should be dynamically
negotiated and adjusted in time.
Another, for the case of multiple participants,  it may need the mix of
multiple media streams. Each particiapating client may support different
media format and the media format that is used for the realtime
communication may be different to the format to be recorded by server given
the cost and efficiency for servers.
So, may we add two new requirements as following:
"The mechanism MUST support dynamic adjustment on formats and bandwidths for
transporting media."
"The mechanism MUST support media transform in the media recording session."

Thanks.
Zhipeng

-----Original Message-----
From: Elwell, John [mailto:[email-masked]] 
Sent: Monday, May 24, 2010 6:16 PM
To: zhipeng zhou; [email-masked]; [email-masked]
Subject: RE: [siprec] siprec Digest, Vol 3, Issue 50

Zhipeng,

The range of media formats and bandwidths that a SRS will support will be a
matter of policy for a given deployment, and outside the scope of siprec.
Clearly there has to be a mechanism for negotiating formats and bandwidths
to be used, and I don't see a requirement addressing that at present. So
would addition of a requirement along the lines of the following be
sufficient to satisfy your concern?
"The mechanism MUST provide a means for the SRC and SRS to agree on media to
be recorded and on formats and bandwidths for transporting those media to
the SRS."

John (as individual)

> Particularly some new industry solutions for the media communication 
> (such as flv) have been widely used and will appear continually.
> So, for any multimedia solution it should be important to keep open 
> for multiple media types.
> While, for clients, they always have different kind of terminals. So 
> the terminals have different capabilties for the media 
> communication.For example my mobile phone does not support flv.
> Hence, to negotiate a proper media type between server and client in 
> the application is very important.
> For the bandwidth, it is very similar that on different communiation 
> session the bandwidth is different. For example some are based on 3G 
> wireless and some are based on  GPRS. So it should be required for the 
> recording system to support a wide rate range for multimedia 
> communications.
> Of course, that
> applications require the recording server to issue appropriate media 
> steams to be adapted to the client's media capability and the network 
> bandwidth.
> During the realtime media communication, either the media's tranport 
> rate or the media types or the video framesize may be adjusted.
> I have difficulty understanding the use case. In particular, the text 
> "the recording server to issue appropriate media steams" seems to 
> suggest we are talking about playback, which is outside the scope of 
> siprec.
> If this is not
> the right interpretation of this text, please explain the use case 
> more clearly. Once we have established a clear use case and determined 
> whether it will have impact on siprec, we can open a new issue if 
> appropriate.
> 
> John (as chair)
> 
>

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 25 May 2010 08:37:06 +0200

Zhipeng,

> Sent: 25 May 2010 07:12
[JRE] (as individual) I suspect we will need some more motivation for this. Also  it might be something we can defer to a later phase.

> "The mechanism MUST support media transform in the media
[JRE] (as individual) If I understand correctly, you want to have support for a third entity in the path between the SRC and the SRS for the purpose of transforming media formats. On the one hand, there are already RFCs documenting transcoding solutions for use with SIP, so we could perhaps use one of these. On the other hand, I am not sure whether they would work as they stand for session recording. Again, this might be something we can defer to a later phase.

[JRE] (as chair). If you want to pursue these two new requirements, I suggest you raise separate issues on the tracker so that they don't get forgotten. Concerning the requirement on negotiation, for which I proposed text, I have added this as a comment on existing issue #4 ("media coding negotiation").

John

> > > When replying, please edit your Subject line so it is
> more specific
> > > than
> milestone1
> milestone1

---

From: zhipeng zhou <[email-masked]>
Date: Tue, 25 May 2010 14:53:42 +0800

Hi John,
I have two responses below. And you work so early.
Thanks.
Zhipeng

-----Original Message-----
From: Elwell, John [mailto:[email-masked]] 
Sent: Tuesday, May 25, 2010 2:37 PM
To: zhipeng zhou; [email-masked]; [email-masked]
Subject: RE: [siprec] siprec Digest, Vol 3, Issue 50

Zhipeng,

> Except your suggested additional requirement, we'd consider the 
> features of real time since it is closely related to the quality.
> For example, if the big delay happens, the session should be 
> dynamically negotiated and adjusted in time.
> Another, for the case of multiple participants,  it may need the mix 
> of multiple media streams. Each particiapating client may support 
> different media format and the media format that is used for the 
> realtime communication may be different to the format to be recorded 
> by server given the cost and efficiency for servers.
> "The mechanism MUST support dynamic adjustment on formats and 
> bandwidths for transporting media."
[JRE] (as individual) I suspect we will need some more motivation for this.
Also  it might be something we can defer to a later phase.

> "The mechanism MUST support media transform in the media recording 
[JRE] (as individual) If I understand correctly, you want to have support
for a third entity in the path between the SRC and the SRS for the purpose
of transforming media formats. On the one hand, there are already RFCs
documenting transcoding solutions for use with SIP, so we could perhaps use
one of these. On the other hand, I am not sure whether they would work as
they stand for session recording. Again, this might be something we can
defer to a later phase.
[ZP] My supposed issue is not quite new in fact. You can see the REQ-012 has
claimed the issue for mixed media streams. And to support these requirements
the industry have rather mature solutions while the Requirement and
Architecture document have to clarify these. They are indeed necessay
functionalities for the recording system.
Another, may you pick out which RFC you are referring to for the transcoding
solutions? Thanks.

[JRE] (as chair). If you want to pursue these two new requirements, I
suggest you raise separate issues on the tracker so that they don't get
forgotten. Concerning the requirement on negotiation, for which I proposed
text, I have added this as a comment on existing issue #4 ("media coding
negotiation").
[ZP] Ok, I can add them on the tracker.

John

> The range of media formats and bandwidths that a SRS will support will 
> be a matter of policy for a given deployment, and outside the scope of 
> siprec.
> Clearly there has to be a mechanism for negotiating formats and 
> bandwidths to be used, and I don't see a requirement addressing that 
> at present. So would addition of a requirement along the lines of the 
> following be sufficient to satisfy your concern?
> "The mechanism MUST provide a means for the SRC and SRS to agree on 
> media to be recorded and on formats and bandwidths for transporting 
> those media to the SRS."
>
> John (as individual)
>

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 25 May 2010 09:30:25 +0200

> Sent: 25 May 2010 07:54
[JRE] (as individual) REQ-012 is concerned with mixing at the SRC. However, I thought you were asking for an intermediate entity to perform transcoding. These seem to be two quite separate requirements, in my opinion.

> Another, may you pick out which RFC you are referring to for
[JRE] RFC 5369, RFC 5370, RFC 4117.

John

> > > > recording system that does not support this requirement
> for media
> > > > adjusting.
> > > >
> > > > Thanks.
> > > > Zhipeng
> > > >
> > > >
> > > > Message-ID:
> <[email-masked]>
> > > > Message-ID:
> <[email-masked]>
> > > > Message-ID:
> <[email-masked]>
> > > > Message-ID:
> <[email-masked]>

---

From: zhipeng zhou <[email-masked]>
Date: Tue, 25 May 2010 15:49:09 +0800

Hi John,
Fyi that the note says "A mixed media stream is typically produced by a
mixer function." 
The mixer needs to collect multiple streams and mix them so will not reside
on one client.

Thanks.
Zhipeng

-----Original Message-----
From: Elwell, John [mailto:[email-masked]] 
Sent: Tuesday, May 25, 2010 3:30 PM
To: zhipeng zhou; [email-masked]; [email-masked]
Subject: RE: [siprec] siprec Digest, Vol 3, Issue 50

> [JRE] (as individual) If I understand correctly, you want to have 
> support for a third entity in the path between the SRC and the SRS for 
> the purpose of transforming media formats. On the one hand, there are 
> already RFCs documenting transcoding solutions for use with SIP, so we 
> could perhaps use one of these. On the other hand, I am not sure 
> whether they would work as they stand for session recording. Again, 
> this might be something we can defer to a later phase.
> [ZP] My supposed issue is not quite new in fact. You can see the 
> REQ-012 has claimed the issue for mixed media streams. And to support 
> these requirements the industry have rather mature solutions while the 
> Requirement and Architecture document have to clarify these. They are 
> indeed necessay functionalities for the recording system.
[JRE] (as individual) REQ-012 is concerned with mixing at the SRC. However,
I thought you were asking for an intermediate entity to perform transcoding.
These seem to be two quite separate requirements, in my opinion.

> Another, may you pick out which RFC you are referring to for the 
> transcoding solutions? Thanks.

John

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 25 May 2010 10:40:26 +0200

Zhipeng,

Yes, but it says nothing about the mixer function being separate from the SRC. Perhaps we don't need anything further in the requirements document, but instead can consider the need for a mixer function separated from both the SRC and the SRS as part of the architecture document. However, I am still of the opinion this is something we can omit from phase 1.

John (as individual)

> Sent: 25 May 2010 08:49
> > [JRE] (as individual) I suspect we will need some more
> motivation for
> > this.
> > > "The mechanism MUST support media transform in the media
> recording
> > > session."

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 25 May 2010 09:18:07 -0400

Zhipeng,

I've looked through the ensuing discussion, but still I don't think I 
understand precisely what you are requesting here.

Are you suggesting that the negotiation of the media formats used for 
the CS be influenced by the preferences and capabilities of the SRC 
and/or SRS, or some transcoder between them?

	Thanks,
	Paul

---

From: Brian Rosen <[email-masked]>
Date: Tue, 25 May 2010 09:29:14 -0400

<as individual>
It may be that I am also confused, but at least I am under the delusion that
I understand what is asked for.

I would say that the recording server negotiates media with the client using
normal SDP negotiation. The procedures in RFC5369 to invoke a transcoder
could be used, as they could be used in any SIP session establishment.  A
reference to 5369 would be appropriate, but no normative text is needed.

Brian

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 25 May 2010 09:51:33 -0400

> reference to 5369 would be appropriate, but no normative text is needed.

Well, I think it goes without saying that the sip session between the 
SRC and the SRS is indeed a sip session, and so all the normal sip 
mechanisms should be in play while establishing it.

But the SRC may be be at the mercy of what is negotiated for the CS. 
Unless it has its own transcoder, or is in a position to influence the 
media format selection for the CS, it will have to take whatever is 
selected for the CS and offer that to the SRS. There then won't be any 
room for negotiation, and so the SRS had better be prepared for whatever 
it gets.

I presume the SRS will typically be a much more capable device than many 
of the CS participants, so it will normally be the one that can deal 
with what it gets. If it needs to recruit a transcoder for certain 
formats it can certainly do so without introducing any additional 
complexity on other elements.

*IF* the SRS has limits to the formats it can handle, *and* the SRC is 
in a position to influence the O/A exchanges for the CS (because it is a 
participant) then it can let the SRS limitations influence the CS O/A, 
but I would hope that doen't need to be something this group must 
explicitly address.

	Thanks,
	Paul

---

From: Brian Rosen <[email-masked]>
Date: Tue, 25 May 2010 10:03:23 -0400

<as individual>
Agree.  No normative text needed, some informative text may be helpful.

Brian

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 25 May 2010 16:24:49 +0200

> [mailto:[email-masked]] On Behalf Of Brian Rosen
> Sent: 25 May 2010 15:03
> To: Paul Kyzivat
> Cc: [email-masked]; zhipeng zhou
[JRE] (as individual) In which document(s) - reqs, arch or solution? I am not convinced we need a requirement on this, but some informative mention in the architecture document might be appropriate.

John

> >>>> "The mechanism MUST support dynamic adjustment on
> formats and bandwidths
> >>>> for
> >>>> transporting media."
> >>>> "The mechanism MUST provide a means for the SRC and SRS
> to agree on media
> >>>> to
> >>>>>> recording system that does not support this
> requirement for media
> >>>>>> adjusting.
> >>>>>>
> >>>>>> Thanks.
> >>>>>> Zhipeng
> >>>>>>
> >>>>>>

---

From: Brian Rosen <[email-masked]>
Date: Tue, 25 May 2010 10:31:36 -0400

<as individual>
Agree, no requirement, some informative text in architecture.

On 5/25/10 10:24 AM, "Elwell, John" <[email-masked]>
wrote:

> [JRE] (as individual) In which document(s) - reqs, arch or solution? I am not
> convinced we need a requirement on this, but some informative mention in the
> architecture document might be appropriate.
> 
> John
> 
>> 
>> Brian
>> 
>>