On 8/22/12 3:57 PM, Paul Hoffman wrote:
On Aug 22, 2012, at 1:33 PM, Robert Sparks <[email protected]> wrote:
1) Why don't we have requirements that discuss reusing the
identities we already have with IETF systems (like the tracker login)?
If we reuse the identities, then the registrant has not done the round-trip
required in 06-13. This also allows someone to pick a meeting-specfic email
address.
Are you reading that requirement to say that we must implement it by
having people join an email list?
That's a reasonable mechanism to consider, but not necessarily the only one.
I could see having a page on the datatracker that once you've logged in
(which means you've established
credentials), you have the option to sign up as a remote participant for
an upcoming meeting. That page
could run you through the note-well confirmation, give you the
opportunity to be added to a meeting-specific email address with
whatever email address you wanted to provide.
The rps system could then use the datatracker logins for that meeting,
checking to see if the person had actually registered. One less password
for people to remember (and perhaps one more reason for people to not
just share the credentials from one registration).
Alternatively, it could negotiate a new token at the point of
registration that the user could use as the simple password, but what
would that extra complexity buy?
2) 06-41 and 06-42 appear to be in conflict. Is the second sentence of
06-41 not talking about exactly 06-42?
Err, yes. The second sentence of 06-41 should be all of 06-42. I'll fix this in
the -07.
3) 06-65 - Why is this SHOULD and not MUST? Having an easy mechanism for
indexing the audio stream in real-time is a request I've heard for
years, and the suggested uses go beyond noting changes in speaker.
It's a SHOULD because there is no widely-agreed to standard for such indexing.
Thus, people should not rely on the first results being stable or even being
continued over the long term.
Could you state in the document that this is a frequent feature request?
I would like to encourage whoever looks at implementing this to ask
questions.
4) In 06-78, Can you expand on what "prepare" means? Do you only mean select
which tools will be used, or do you mean also configuring the tools, or putting
data
in them. If there's something even more you have in mind, it would be good to be
explicit. As written, if I were building this system, all I can think to do to
meet the
requirement is provide a list of checkboxes before the session to know which
tool
to enable for that session.
Initially, "prepare" might only mean "select", but there might be some
configuration that can be done easily as well. However, we don't know what that is yet.
This is a requirement. What requirement do we actually have right now?
5) 06-81 - It should be clearer that this is the "call here to ensure your
voice and video are set up correctly" test. It's testing the client, not the
service.
Good point. Will be clarified in -07.
--Paul Hoffman
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html.
https://www.ietf.org/mailman/listinfo/vmeet
