Subject: Re: [siprec] comments on draft-ietf-siprec-req-02 REQ-021

From: "Elwell, John" <[email-masked]>
Date: Tue, 2 Nov 2010 15:46:58 +0100

I didn't see any response to this, and the requirement still exists in -04. Can we delete REQ-021?

John 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Paul Kyzivat
> Sent: 28 September 2010 14:34
> To: [email-masked]
> Subject: [siprec] comments on draft-ietf-siprec-req-02 REQ-021
> 
> > REQ-021 Metadata format must be agnostic of the transport protocol.
> 
> 
> IMO this requirement is dubious or at least requires clarification.
> 
> Is the goal that the metadata *as stored* by the SRS must be 
> agnostic to 
> transport? Or is it that that encoding of the metadata *when 
> transmitted* to the SRS must be encoded in a transport agnostic way?
> 
> Some of the metadata will be most naturally gathered 
> opportunistically 
> from the transport. For instance codec information. That 
> would make it 
> non-agnostic to the transport.
> 
> 	Thanks,
> 	Paul
> _______________________________________________
> siprec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/siprec
>

---

From: Leon Portman <[email-masked]>
Date: Tue, 2 Nov 2010 16:59:35 +0200

Actually the drive for this requirement was that metadata can be delivered via different transport protocols: SIP INVITE, Subscribe/notify, Info, HTTP, etc. It does not relates to actual transport protocol of CS.

And we wanted that metadata definition (xml schema) will be agnostic to Metadata transport and not CS or RS transport
May be we should phrase it like this:
 
REQ-021 Metadata format must be agnostic of the metadata transport protocol

Leon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Elwell, John
Sent: Tuesday, November 02, 2010 4:47 PM
To: Paul Kyzivat; [email-masked]
Subject: Re: [siprec] comments on draft-ietf-siprec-req-02 REQ-021

John

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 02 Nov 2010 11:36:46 -0400

Leon,

Your response is still not to the point. Specifically, if there is some 
information that we want to retain as metadata, which is "naturally" 
available via sip signaling between SRC and SRS, but which then is 
"transport specific", do we need to define some other transport-agnostic 
way to send it?

Consider the codec info that is naturally available in the SDP between 
SRC and SRS. Do we need to define some other way to send that, which is 
transport agnostic? And if so, do we need to use that way?

ISTM that we only need to be transport agnostic while we are gathering 
the detailed requirements on what needs to be conveyed. Once we get down 
to selecting the transport mechanism for each bit of the metadata, I 
think we no longer need to be transport agnostic.

The situation may be different for *retrieving* metadata. But that is 
out of scope for now.

	Thanks,
	Paul

---

From: Leon Portman <[email-masked]>
Date: Tue, 2 Nov 2010 17:42:27 +0200

Paul, Hi

I agree that metadata is transport specific in relation to the transport layer of CS like the codec example.
But I am still missing the point why the actual format of metadata should be dependent on over which transport protocol we will send it?

Leon

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Tuesday, November 02, 2010 5:37 PM
To: Leon Portman
Cc: Elwell, John; [email-masked]
Subject: Re: [siprec] comments on draft-ietf-siprec-req-02 REQ-021

Leon,

	Thanks,
	Paul

---

From: Leon Portman <[email-masked]>
Date: Tue, 2 Nov 2010 17:47:06 +0200

Just one additional comment:

Codec info that will be available in SDP between SRC and SRS not always will represent the codec in CS because of mixing and transcoding.
So we still need to define way to convey via the metadata. Same is for SIP header parameters : to, from ,contact, via etc.

Leon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Leon Portman
Sent: Tuesday, November 02, 2010 5:42 PM
To: Paul Kyzivat
Cc: [email-masked]
Subject: Re: [siprec] comments on draft-ietf-siprec-req-02 REQ-021

Paul, Hi

Leon

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Tuesday, November 02, 2010 5:37 PM
To: Leon Portman
Cc: Elwell, John; [email-masked]
Subject: Re: [siprec] comments on draft-ietf-siprec-req-02 REQ-021

Leon,

	Thanks,
	Paul

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 2 Nov 2010 17:52:45 +0100

Leon,

I think there is the possibility that different fragments of metadata will be delivered over different transports, but for a given fragment the transport might be fixed. For example, for some fragments we might decide they are conveyed as SIP header fields in messages on the RS, whereas others might be conveyed as MIME body parts in such messages, and yet others might be conveyed by HTTP. But I don't think we really want to make any particular fragment transport-agnostic. Or put it another way, I would not necessarily preclude a solution that makes metadata transport-agnostic, but I would not want to impose that constraint on our work by stating it as a requirement.

John (as individual) 

> From: Leon Portman [mailto:[email-masked]] 
> Sent: 02 November 2010 15:42
> To: Paul Kyzivat
> Subject: RE: [siprec] comments on draft-ietf-siprec-req-02 REQ-021
> 
> Paul, Hi
> 
> I agree that metadata is transport specific in relation to 
> the transport layer of CS like the codec example.
> But I am still missing the point why the actual format of 
> metadata should be dependent on over which transport protocol 
> we will send it?
> 
> Leon
> 
> > Actually the drive for this requirement was that metadata 
> can be delivered via different transport protocols: SIP 
> INVITE, Subscribe/notify, Info, HTTP, etc. It does not 
> relates to actual transport protocol of CS.
> >
> > And we wanted that metadata definition (xml schema) will be 
> agnostic to Metadata transport and not CS or RS transport
> [mailto:[email-masked]] On Behalf Of Elwell, John
> > I didn't see any response to this, and the requirement 
> still exists in -04. Can we delete REQ-021?
> >
> > John
> >

---

From: "Hutton, Andrew" <[email-masked]>
Date: Tue, 2 Nov 2010 18:11:20 +0100

I agree it seems that REQ-21 does not make sense anymore.

It probably dates back from the days when we thought that metadata would be delivered to the RS as an XML document but now we are stating that it could be obtained from many sources.

Regards
Andy

> Sent: 02 November 2010 16:53
> To: Leon Portman; Paul Kyzivat
> Cc: [email-masked]
> I think there is the possibility that different fragments of 
> metadata will be delivered over different transports, but for 
> a given fragment the transport might be fixed. For example, 
> for some fragments we might decide they are conveyed as SIP 
> header fields in messages on the RS, whereas others might be 
> conveyed as MIME body parts in such messages, and yet others 
> might be conveyed by HTTP. But I don't think we really want 
> to make any particular fragment transport-agnostic. Or put it 
> another way, I would not necessarily preclude a solution that 
> makes metadata transport-agnostic, but I would not want to 
> impose that constraint on our work by stating it as a requirement.
> 
> John (as individual) 
>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 02 Nov 2010 13:19:03 -0400

> But I am still missing the point why the actual format of metadata should be dependent on over which transport protocol we will send it?

My point is that if SRS can gather the codec information directly from 
its native form in the SDP of the sip signaling it gets from the SRC, 
then there is no need to send/encode it some other way. I'm assuming 
that probably the codec info that is exchanged on CS is the same as what 
is exchanged on RS.

*If* the codec info exchanged on the CS might be *different* from the 
codec info on the RS, and its necessary to pass that info to the SRS via 
some sort of *explicit* metadata exchange, then having it be transport 
agnostic would make sense to me.

It sounds like you are concerned with how the SRS encodes it for storage 
after it receives it. But we aren't defining that.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 02 Nov 2010 13:24:30 -0400

If there is need to convey a lot of the CS signalnig info to the SRS, we 
might want to consider tunneling pretty much all of the CS sip signaling 
down to the SRS, perhaps in its native form.

On 11/2/2010 11:47 AM, Leon Portman wrote:
> So we still need to define way to convey via the metadata.

Do you think they will differ often enough that this should always be 
sent as explicit metadata? Or is this the exception rather than the 
rule, so that we might plan to use the info passed directly in SDP 
between SRC and SRS, with exceptions when needed?

> Same is for SIP header parameters : to, from ,contact, via etc.

Clearly we need to convey participant information that won't be there 
naturally in the RS.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 07 Nov 2010 09:18:02 -0500

I'm not the one to say.

I thought I saw a message of agreement from Leon.

	Thanks,
	Paul

---

From: Leon Portman <[email-masked]>
Date: Mon, 8 Nov 2010 03:28:21 +0200

Yes, I agree to remove. However it is still should be our design goal at least to try to make it agnostic for Metadata transport protocol.

Leon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: Sunday, November 07, 2010 4:18 PM
To: Elwell, John
Cc: [email-masked]
Subject: Re: [siprec] comments on draft-ietf-siprec-req-02 REQ-021

I'm not the one to say.

	Thanks,
	Paul